From: tlaronde@polynum.com
To: Pedro Falcato <pedro.falcato@gmail.com>
Cc: devel@edk2.groups.io
Subject: Re: [edk2-devel] EmulatorPkg: fixes for NetBSD compilation
Date: Tue, 22 Nov 2022 09:35:11 +0100 [thread overview]
Message-ID: <Y3yJv9ckxRTuV24m@polynum.com> (raw)
In-Reply-To: <CAKbZUD2oJzPp_pH+dBvJBEa-1XX7xaEvVo_SnB8Oi7PUSh7u0w@mail.gmail.com>
Hello Pedro,
Le Mon, Nov 21, 2022 at 10:32:51PM +0000, Pedro Falcato a écrit :
> On Mon, Nov 21, 2022 at 9:21 PM <tlaronde@polynum.com> wrote:
>
> > diff --git a/EmulatorPkg/Unix/Host/BlockIo.c
> > b/EmulatorPkg/Unix/Host/BlockIo.c
> > index cf2d6b4cda..c0c694be55 100644
> > --- a/EmulatorPkg/Unix/Host/BlockIo.c
> > +++ b/EmulatorPkg/Unix/Host/BlockIo.c
> > @@ -133,6 +133,20 @@ EmuBlockIoOpenDevice (
> >
> > ioctl (Private->fd, DKIOCGETMAXBLOCKCOUNTWRITE,
> > &Private->Media->OptimalTransferLengthGranularity);
> > }
> > + #elif _NETBSD_SOURCE
> > + {
> > + u_int BlockSize;
> >
> Hi,
>
> Again, thanks for the patches. Please send them in the way I kind of
> described in my other reply.
>
> s/u_int/UINT/
>
> + off_t DiskSize;
> >
> I think this off_t is fine, per the other off_t usages, I don't know if the
> maintainers agree.
>
> > +
> > + if (ioctl (Private->fd, DIOCGSECTORSIZE, &BlockSize) == 0) {
> > + Private->Media->BlockSize = BlockSize;
> > + }
> > +
> > + if (ioctl (Private->fd, DIOCGMEDIASIZE, &DiskSize) == 0) {
> > + Private->NumberOfBlocks = DivU64x32 (DiskSize,
> > (UINT32)BlockSize);
> > + Private->Media->LastBlock = Private->NumberOfBlocks - 1;
> > + }
> > + }
> > #else
> > {
> > size_t BlockSize;
> >
>
>
> > diff --git a/EmulatorPkg/Unix/Host/Host.c b/EmulatorPkg/Unix/Host/Host.c
> > index 38c01c84af..c505300129 100644
> > --- a/EmulatorPkg/Unix/Host/Host.c
> > +++ b/EmulatorPkg/Unix/Host/Host.c
> > @@ -12,6 +12,12 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> > #define MAP_ANONYMOUS MAP_ANON
> > #endif
> >
> > +#ifdef _NETBSD_SOURCE
> > +#define MAP_ANON_FD_ (-1)
> > +#else
> > +#define MAP_ANON_FD_ (0)
> > +#endif
> >
> Would there be a harm if we just passed -1 everywhere? It's a bit odd
> NetBSD explicitly requires this, but AFAIK implementations
> either EINVAL on fd != -1 or take whatever since it's anon. The main
> implementations (Linux, FreeBSD, NetBSD, OpenBSD, macOS) seem to
> agree that passing -1 should be safe everywhere (in fact, it's pretty funny
> that all BSD-derived implementations agree with the fd = -1 thing, but I
> digress).
Since MAP_ANON is not specified by POSIX1, I tend to think that what is
not in POSIX should be explicitely set in the code.
So if other OSes (with which edk2 is used) agree on (-1), my personal
taste would be to keep at least the define macro:
#define MAP_ANON_FD_ (-1)
as an indication that the definition is not standard (so that someone
with a system choking on this, could easily spot the culprit). (The
trailing underscore is because leading ones shall be reserved for
standard or system implementation, and the trailing is a way to indicate
that the macro is somehow local. Is there a convention for this in
EDK2?)
Best,
--
Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
prev parent reply other threads:[~2022-11-22 8:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-21 13:08 EmulatorPkg: fixes for NetBSD compilation tlaronde
2022-11-21 22:32 ` [edk2-devel] " Pedro Falcato
2022-11-22 8:35 ` tlaronde [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=Y3yJv9ckxRTuV24m@polynum.com \
--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