From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by mx.groups.io with SMTP id smtpd.web10.790.1574440336106770999 for ; Fri, 22 Nov 2019 08:32:16 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=JnH0YxhX; spf=pass (domain: linaro.org, ip: 209.85.128.68, mailfrom: leif.lindholm@linaro.org) Received: by mail-wm1-f68.google.com with SMTP id z19so8318579wmk.3 for ; Fri, 22 Nov 2019 08:32:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=zjmapL4ll0fAJv4i6TxPc3KGnznyenT0AFBKwS16xiM=; b=JnH0YxhXxEOSElkf0f5jXxKWrUEzm2bAPMnpSva2MWeUyFjeKnrzvex9UEqPBZPu8D 5l7Fqci6jQ0sunbYyXKMFFEKuhwp+O/+bxsAomWxLcxYqyQgD/wceYO8lLg+CpnBQ5cW 1iqQhs0zB7ZX/4nSLbPKbfI1rqGpOYDt/XRTzgKxwb2AXX4QKSV6/dRUF/WgODMcvQro cpSTc33yHiV1Vs5qCMnV7/PT+dHjhS4SbTaq+7tS7pzHTWTP7O7ukgduWp/JjWkCXd7y hHVsy6IQz2I5DuFD+dEpsFN5mN+BNeFvdV0fJeG4AmmybS24DozquJSy1CjV+DdiiXMj 4Wug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=zjmapL4ll0fAJv4i6TxPc3KGnznyenT0AFBKwS16xiM=; b=OYFdycb9PE7nNtvC67MdPHMEEh2PJ1NxiqyWPrtElCe1N3G4YgYf9i6ovn+24qWM5Z fGR47ES3flIOKVQyGCobY8T3E62fYq+n5gDqU39hTWvTxuSGLeZnhpr3p0nL9yCHnOe2 tITKjJGiVN7d2aFHD3DR3PqACedivp8wQWT+pEK8Xq7/lAVpGmKFLsKmU3vkeyWkoHxU kFtLBf5ALbm3SsexsaNpK3Xo/T+7mmkqFWr9aBGiYJrw7eg5j6zdHAkyhmvEpSXmLopO qCF5CBhEZemmiu4DU2djKLj5kqlRS7B1ggBNQbxXZMtaImK0vzA+vqGa0+bZleE4KNJ2 HbDQ== X-Gm-Message-State: APjAAAXZEx60ECLcH0oZoPfng9HTOlFxnRwukwkH3lFhhgOqlUvtq4dk DiphjdlNfvJfOoCQFAcEagE8rntLw84= X-Google-Smtp-Source: APXvYqzb01EUoSaX8luv3OjJ8fmQvFIzMcTFY55QWns21mUG0w9zaYIItN9VlQHWhfC1NiPQFcscnQ== X-Received: by 2002:a1c:9646:: with SMTP id y67mr17005720wmd.79.1574440334054; Fri, 22 Nov 2019 08:32:14 -0800 (PST) Return-Path: Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id y6sm8368273wrw.6.2019.11.22.08.32.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Nov 2019 08:32:13 -0800 (PST) Date: Fri, 22 Nov 2019 16:32:11 +0000 From: "Leif Lindholm" To: devel@edk2.groups.io, abner.chang@hpe.com Cc: "Chen, Gilbert" Subject: Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v3 29/39] RiscVPlatformPkg/RealTimeClockLibNull: Null instance of RTC lib. Message-ID: <20191122163210.GI7359@bivouac.eciton.net> References: <1572227957-13169-1-git-send-email-abner.chang@hpe.com> <1572227957-13169-30-git-send-email-abner.chang@hpe.com> <20191121170254.GP7359@bivouac.eciton.net> <20191122140835.GF7359@bivouac.eciton.net> <20191122145547.GH7359@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Nov 22, 2019 at 16:05:07 +0000, Abner Chang wrote: > > > > Sure, but we also don't *need* to add a new implementation for this > > > > - RiscVPkg can still use the EmbeddedPkg one. > > > > > > > > (And if we did, it should probably be in MdeModulePkg.) > > > > > > I think we had similar discussion about this before. My comment was > > > RiscVPkg as a processor package should not have dependence with > > > EmbeddedPkg. > > > > This is not RiscVPkg though, this is RiscVPlatformPkg. > > And also, it does not appear to be used there anyway? > > Same comments from me for RiscVPlatformPkg. I don't see any reasons > to have dependence with EmbeddedPkg in RiscVPlatformPkg as > RiscVPlatformPkg is a generic RISC-V platform modules . Platform > such as U540 could choice which RTC instance it needs. I don't think there is any particular inherent aspect about EmbeddedPkg being more evil or unreliable than MdeModulePkg. If anything, it suffers from poor naming. (Basically, it was the staging area for bringing a bunch of !x86 stuff into the tree, and the first platform port was to an embedded board...) But more importantly, RealTimeClockLib is only used by EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf, so it's a bit difficult to argue that EmbeddedPkg is an unsuitable source for the library. We will at some point do an overhaul of the directory tree, so getting hung up on current package names isn't a worthwhile investment. The only real exceptions to this are MdePkg and MdeModulePkg, which should not depend on any other packages. And I tend to argue even about that. > > Certainly I can still build RiscVPlatformPkg.dsc if I delete that > > library mapping. > > We can remove this one and create a null one in MdePkg which is akin > to the null instance of TimerLib. I have no issue with that as such. I also don't see a value. A RealTimeClockLibNull is only useful for enabling compilation of incomplete platforms (and as such, if it was included in MdeModulePkg, it should probably have unconditional ASSERTs added to all functions). Whereas VirtualRealTimeClockLib can ameliorate the situation of not having a persistent RTC in the system. But for the purpose of this set, please just drop this patch and any references to this module. / Leif