[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMj1kXG9zkGGEQRXv41ro2mwZBcSvO=UJXfN5Aemu4CmBHkVxA@mail.gmail.com>
Date: Wed, 21 May 2025 17:10:55 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Peter Jones <pjones@...hat.com>
Cc: Pali Rohár <pali@...nel.org>,
David Howells <dhowells@...hat.com>, linux-efi@...r.kernel.org, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] include: pe.h: Fix PE definitions
On Wed, 21 May 2025 at 16:11, Peter Jones <pjones@...hat.com> wrote:
>
> On Wed, May 21, 2025 at 03:45:13PM +0200, Ard Biesheuvel wrote:
> > (cc Peter)
> >
> > On Mon, 5 May 2025 at 19:33, Pali Rohár <pali@...nel.org> wrote:
> > >
> > > Hello Ard!
> > >
> > > On Monday 05 May 2025 13:25:45 Ard Biesheuvel wrote:
> > > > Hello Pali,
> > > >
> > > > On Sun, 4 May 2025 at 20:23, Pali Rohár <pali@...nel.org> wrote:
> > > > >
> > > > > * Rename constants to their standard PE names:
> > > > > - MZ_MAGIC -> IMAGE_DOS_SIGNATURE
> > > > > - PE_MAGIC -> IMAGE_NT_SIGNATURE
> > > > > - PE_OPT_MAGIC_PE32_ROM -> IMAGE_ROM_OPTIONAL_HDR_MAGIC
> > > > > - PE_OPT_MAGIC_PE32 -> IMAGE_NT_OPTIONAL_HDR32_MAGIC
> > > > > - PE_OPT_MAGIC_PE32PLUS -> IMAGE_NT_OPTIONAL_HDR64_MAGIC
> > > > > - IMAGE_DLL_CHARACTERISTICS_NX_COMPAT -> IMAGE_DLLCHARACTERISTICS_NX_COMPAT
> > > > >
> > > >
> > > > Where are these 'standard PE names' defined?
> > >
> > > Basically in any project which is doing something with PE, at least in
> > > projects which I saw or used it. Those names are mostly coming from
> > > Windows SDKs/WDKs as the Microsoft is inventor of them and are de-facto
> > > standard names -- or at least people are following existing naming
> > > convention for a good reasons. If you are are not familiar with
> > > MS/Windows world, you can find them also in projects like binutils,
> > > llvm/clang, wine or mingw-w64, which are hopefully well-known project
> > > references.
> > >
> > > Some of IMAGE_DLLCHARACTERISTICS_* names (including the NX_COMPAT) are
> > > defined also in the PE MS spec (win32/debug/pe-format). I hope that this
> > > spec can be taken as a reference, even that it does not document
> > > everything related to PE, and contains mistakes.
> >
> > I don't feel strongly either way with any of this - I don't think
> > there's anything to fix here, but I'm not attached to the names so I
> > don't mind changing them either.
> >
> > Peter: any thoughts?
>
> I'm broadly for making the names look more like what the spec uses
> whenever we can when it doesn't introduce naming collisions with other
> stuff. But like you, it makes very little difference to me.
>
Thanks for the insight.
I've queued it up now - thanks.
Powered by blists - more mailing lists