From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by mx.groups.io with SMTP id smtpd.web11.25969.1613943221251814331 for ; Sun, 21 Feb 2021 13:33:41 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=082Y/ssD; spf=pass (domain: nuviainc.com, ip: 209.85.221.53, mailfrom: leif@nuviainc.com) Received: by mail-wr1-f53.google.com with SMTP id l30so1363575wrb.12 for ; Sun, 21 Feb 2021 13:33:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=IIu9qlWdrTYAP31M+sajXO2mYTf5ouIppIxeQ0kE7nE=; b=082Y/ssDH/kp53fvrsxoFDECxQ+jlTAKyOwPENRk2zClotF+EetjRLxd/c4VHGSOkC Q9hTeaHGqoTqOzdlKM2H8J06ALnZoO8iIEH2xpWKEz2jmp3IVnA0qi4jGWnH6V/546DS IXYtOXbOHaPpvOFNPfud++8Cqf8/vfb7Eu0GCOyawRIGG9vyFMNIaTRjA/6UFh0QESxg B3fR5lUJp0kL/A7OvP7LQ/cluPAJoRP1zHGFugjCpvKGezBJ5V5Ah6bsJ80XPZSPM4QV C+SqlFGb29f2OP2FvOJwG8xuavTK+abeaAV1lu2pa5gnR0VLfvvArB97jN/lCG1n2dFC LjIg== 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=IIu9qlWdrTYAP31M+sajXO2mYTf5ouIppIxeQ0kE7nE=; b=U3w0NaGb5i8s5tGd3F2IZWUdxgc4pRa5u/2z4Zunt79sV090SvvMFVcheBYopVg4XN JxPCvoJiuUGKB+QoS/vrsLX3kY8uKIE7pLExeCieBCCX/zR0q3VR+WpbwYcNa6itXRud g6ndUehD8dreejtGdt42A9X0zSZ0GSPmOHcfwuYH4X278/vjlV6R183zrmgvhL1wKx0q bqN0EFp3yCCHe2WfmbsUaTfJJfsN1G7+B45NAkMkiD8BgSPqdJ6xSflofOB11D0qIQne NrvQNQA3fkUzlx+Ni/XBbs3rdpIbY2lRotSJidZZ1zVwGEoS1ioUTxx8xNMM/jBgXl6d 2c0w== X-Gm-Message-State: AOAM5336KqfMXprA1NGDSD5bLfe8RIFh5+Ox1P2gQnw44AxKwnXS0sWP 9yk25TSAX6ywjieVMjU//rqWFQ== X-Google-Smtp-Source: ABdhPJzu9AcpEc7ppP1VNPV9gBYVxm1Hxa891mGsMBJ8xfQmo4Hjy5myGcKEeClFdb8XuCMzY38xeA== X-Received: by 2002:a05:6000:188c:: with SMTP id a12mr19421307wri.105.1613943219794; Sun, 21 Feb 2021 13:33:39 -0800 (PST) Return-Path: Received: from vanye (cpc1-cmbg19-2-0-cust915.5-4.cable.virginm.net. [82.27.183.148]) by smtp.gmail.com with ESMTPSA id u142sm24072864wmu.3.2021.02.21.13.33.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Feb 2021 13:33:39 -0800 (PST) Date: Sun, 21 Feb 2021 21:33:37 +0000 From: "Leif Lindholm" To: Ard Biesheuvel Cc: Samer El-Haj-Mahmoud , devel@edk2.groups.io, Ard Biesheuvel , Pete Batard Subject: Re: [edk2-platform][PATCH v1 1/1] EmbeddedPkg/VirtualRealTimeClockLib : Reduce DEBUG message verbosity Message-ID: <20210221213337.GP1664@vanye> References: <20210220164133.21746-1-Samer.El-Haj-Mahmoud@arm.com> <20210220214614.GL1664@vanye> <20210221204312.GM1664@vanye> 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 Sun, Feb 21, 2021 at 21:50:20 +0100, Ard Biesheuvel wrote: > On Sun, 21 Feb 2021 at 21:43, Leif Lindholm wrote: > > > > On Sun, Feb 21, 2021 at 11:50:27 +0100, Ard Biesheuvel wrote: > > > On Sat, 20 Feb 2021 at 22:46, Leif Lindholm wrote: > > > > > > > > *How* annoying was this? > > > > > > > > This is kind of useful information, well at the "would be good to see > > > > in a regular DEBUG build" level. > > > > > > > > This change will have suddenly effectively hidden a message that was > > > > already present in many platforms, where they were not (very) annoyingly > > > > repetitive during a normal boot. > > > > > > > > It feels the test suite is not the thing that we need to optimise > > > > debug output for. > > > > > > > > Is there some alternative way we can rate limit this? > > > > > > Given that the sole purpose of this library is to paper over the fact > > > that the platform violates the spec, and lacks the ability to tell > > > time, I think it makes little sense to obsess over how wrong the value > > > is that it returns. > > > > I'm not obsessing about anything, I'm saying that using tediousness > > when running a testsuite as an argument, potential issues with the > > only aspect that makes this implementation useful without having to > > rebuild firmware every few weeks are now hidden. > > > > If we truly don't care about the feature, nuke it. Don't hide when it > > breaks. > > > > Nuke what exactly? I think the library has a use, I simply don't see > the point of reporting 25-50 times every boot that no timestamp was > recorded in a variable. Nuke the variable and always use the build timestamp EPOCH. I would prefer that to silent failure. Or we can figure out and alternative way to stop it spamming the console. The library is declared as a BASE library, but that's clearly untrue as it depends on UefiRuntimeLib. So we could, for example, break out the "check for EPOCH in variable" into a protocol and print the message only once at protocol init. Or we could add a Pcd for "no point, I have no persistent storage". / Leif