From: "Leif Lindholm" <leif@nuviainc.com>
To: Pete Batard <pete@akeo.ie>
Cc: devel@edk2.groups.io, ard.biesheuvel@arm.com
Subject: Re: [PATCH 1/1] EmbeddedPkg/TimeBaseLib: Add macros to get build year/month/day
Date: Mon, 3 Aug 2020 14:00:53 +0100 [thread overview]
Message-ID: <20200803130053.GY31778@vanye> (raw)
In-Reply-To: <06364725-a179-003b-29b8-f75128599bc5@akeo.ie>
Hi Pete,
On Mon, Aug 03, 2020 at 13:21:41 +0100, Pete Batard wrote:
> On 2020.08.03 13:09, Leif Lindholm wrote:
> > Hi Pete,
> >
> > Well prodded (off-list).
> >
> > I expect I saw that arrive, expected the corresponding RPi
> > resubmission to arrive shortly afterwards for me to test with and put
> > it soundly at the back of my mind. Presumably you were waiting for
> > this to be merged before resubmitting that one?
>
> Yes. I tend to find it inconvenient to reference to work that has not yet
> been integrated, as I'm not sure how you're suppose to reference it. Should
> you point to an edk2-devel post in the commit message? In the cover letter?
> Something else?
The cover letter is a good place to describe such dependencies.
We always merge edk2 portions before edk2-platforms, so once it's
merged the only ordering requirement is that your edk2 isn't older
than your edk2-platforms. Hence, we don't really need it in commit
messages.
> As a result, provided the dependency should be simple enough to review
> independently, I prefer to alleviate that issue by just waiting for it to be
> integrated. But if that's a problem, I can certainly ensure that future
> co-dependent patches are submitted together.
In this particular case, it wasn't actually important, we just ended
up with mismatched expectations. Since it was fairly isolated code
that I had already been able to test build in my environments when it
formed part of the original driver.
Regards,
Leif
> > Anyway:
> > Reviewed-by: Leif Lindholm <leif@nuviainc.com>
> > Pushed as bbb8a8185838.
>
> Thanks!
>
> /Pete
>
> >
> > Regards,
> >
> > Leif
> >
> > On Fri, Jul 24, 2020 at 17:37:42 +0100, Pete Batard wrote:
> > > These can be used, for instance, to automate the population of an SMBIOS
> > > Type 0 BIOS Release Date when building a UEFI firmware (which is how we
> > > plan to use these macros for the Raspberry Pi platform).
> > >
> > > These macros should work for any compiler that follows ISO/IEC 9899, but
> > > we add a check for the compiler we have tested to be on the safe side.
> > >
> > > Note that we decided against adding a #error or #warn for compilers that
> > > haven't been validated, as we don't want to introduce breakage for people
> > > who may already be using the header with something else than gcc, MSVC or
> > > Clang. Instead, we expect those to send a patch that adds their compiler
> > > to the list, once they have tested the macros there.
> > >
> > > Signed-off-by: Pete Batard <pete@akeo.ie>
> > > ---
> > > EmbeddedPkg/Include/Library/TimeBaseLib.h | 32 ++++++++++++++++++++
> > > 1 file changed, 32 insertions(+)
> > >
> > > diff --git a/EmbeddedPkg/Include/Library/TimeBaseLib.h b/EmbeddedPkg/Include/Library/TimeBaseLib.h
> > > index 4103c89b3891..ee2f191d985b 100644
> > > --- a/EmbeddedPkg/Include/Library/TimeBaseLib.h
> > > +++ b/EmbeddedPkg/Include/Library/TimeBaseLib.h
> > > @@ -12,6 +12,38 @@
> > > #include <Uefi/UefiBaseType.h>
> > > +//
> > > +// Convenience macros to obtain a build date
> > > +//
> > > +// These macros should work for any compiler that follows ISO/IEC 9899,
> > > +// in which case __DATE__ is defined as a "Mmm dd yyyy" 11 chars string,
> > > +// but add an explicit filter for compilers that have been validated.
> > > +//
> > > +#if (defined(__GNUC__) || defined(_MSC_VER) || defined(__clang__))
> > > +#define TIME_BUILD_YEAR (__DATE__[7] == '?' ? 1900 \
> > > + : (((__DATE__[7] - '0') * 1000 ) \
> > > + + (__DATE__[8] - '0') * 100 \
> > > + + (__DATE__[9] - '0') * 10 \
> > > + + __DATE__[10] - '0'))
> > > +#define TIME_BUILD_MONTH ( __DATE__ [2] == '?' ? 1 \
> > > + : __DATE__ [2] == 'n' ? ( \
> > > + __DATE__ [1] == 'a' ? 1 : 6) \
> > > + : __DATE__ [2] == 'b' ? 2 \
> > > + : __DATE__ [2] == 'r' ? ( \
> > > + __DATE__ [0] == 'M' ? 3 : 4) \
> > > + : __DATE__ [2] == 'y' ? 5 \
> > > + : __DATE__ [2] == 'l' ? 7 \
> > > + : __DATE__ [2] == 'g' ? 8 \
> > > + : __DATE__ [2] == 'p' ? 9 \
> > > + : __DATE__ [2] == 't' ? 10 \
> > > + : __DATE__ [2] == 'v' ? 11 \
> > > + : 12)
> > > +#define TIME_BUILD_DAY ( __DATE__[4] == '?' ? 1 \
> > > + : ((__DATE__[4] == ' ' ? 0 : \
> > > + ((__DATE__[4] - '0') * 10)) \
> > > + + __DATE__[5] - '0'))
> > > +#endif
> > > +
> > > // Define EPOCH (1970-JANUARY-01) in the Julian Date representation
> > > #define EPOCH_JULIAN_DATE 2440588
> > > --
> > > 2.21.0.windows.1
> > >
>
prev parent reply other threads:[~2020-08-03 13:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-24 16:37 [PATCH 1/1] EmbeddedPkg/TimeBaseLib: Add macros to get build year/month/day Pete Batard
2020-08-03 12:09 ` Leif Lindholm
2020-08-03 12:21 ` Pete Batard
2020-08-03 13:00 ` Leif Lindholm [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200803130053.GY31778@vanye \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox