[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bc8307c5-cf59-4a9a-95e1-c49ac19efb43@uncooperative.org>
Date: Wed, 21 May 2025 10:11:23 -0400
From: Peter Jones <pjones@...hat.com>
To: Ard Biesheuvel <ardb@...nel.org>
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, 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.
--
Peter
Powered by blists - more mailing lists