From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp26.services.sfr.fr (smtp26.services.sfr.fr [93.17.128.213]) by mx.groups.io with SMTP id smtpd.web11.14214.1669106115128748613 for ; Tue, 22 Nov 2022 00:35:15 -0800 Authentication-Results: mx.groups.io; dkim=fail reason="no key for verify" header.i=@polynum.com header.s=202006 header.b=NsN9hKVW; spf=pass (domain: sfr.fr, ip: 93.17.128.213, mailfrom: thierry.laronde@sfr.fr) X-mail-filterd: {"version":"1.5.3","queueID":"4NGcyT1zTTz1LQL2Y","contextId": "9e640d45-b4b2-45bf-8895-e737c88f3e10"} Received: from cauchy.polynum.local (20.204.0.93.rev.sfr.net [93.0.204.20]) by msfrf2637.sfr.fr (SMTP Server) with ESMTP id 4NGcyT1zTTz1LQL2Y; Tue, 22 Nov 2022 09:35:13 +0100 (CET) X-mail-filterd: {"version":"1.5.3","queueID":"4NGcyT0Hj0z1LQL20","contextId": "3f21d88f-e9e1-4845-a16d-97a77562e062"} X-sfr-mailing: LEGIT X-sfr-spamrating: 36 X-sfr-spam: not-spam DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=polynum.com; s=202006; t=1669106113; h=Date:From:To:Cc:Subject:References:In-Reply-To; bh=0kULv+HeSA ePCqm8yVDeEnCB340hn1dQ3nM0iWMMQbs=; b=NsN9hKVWDdGMyqS+C8032F8kepZswN9w38LvBn sn7olQxdxLw8ouKgggjEQhQku+Qf4Hk1p5WbVcQzBPAb5HPKXk185OlX9kRBPU5aY35KvWE/s528 HtvPs5M9U7oM/nMtVHwVxqUwvO45qS6ziOzYT88P27FLNKBqlDXPs8GlpgcRdS9nsTcjI+99Ra0Y Ex2l1Zn8E1MYKBqPXUQOe+Bc3PW6grkT3cbhHmGwaa0tWxhd8jpmJJQoDhv9ttBmD5h/qrbfOJrt pCg/PyBHlMukD/7cOW+V6MHCo8eDuyKcFXIregO/7Ms6XSfk62mrmN3VCBP2ORG2iVX6JPVxvnzg == Received: from cauchy.polynum.local (20.204.0.93.rev.sfr.net [93.0.204.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: thierry.laronde@sfr.fr) by msfrf2637.sfr.fr (SMTP Server) with ESMTPSA id 4NGcyT0Hj0z1LQL20; Tue, 22 Nov 2022 09:35:13 +0100 (CET) Authentication-Results: sfr.fr; auth=pass (LOGIN) smtp.auth=thierry.laronde@sfr.fr Received: from cauchy.polynum.local (localhost [127.0.0.1]) by cauchy.polynum.local (8.15.2/8.15.2) with ESMTP id 2AM8ZCxw000723; Tue, 22 Nov 2022 09:35:12 +0100 (CET) Received: (from tlaronde@localhost) by cauchy.polynum.local (8.15.2/8.14.9/Submit) id 2AM8ZBh1000945; Tue, 22 Nov 2022 09:35:11 +0100 (CET) X-Authentication-Warning: cauchy.polynum.local: tlaronde set sender to thierry.laronde@sfr.fr using -f Date: Tue, 22 Nov 2022 09:35:11 +0100 From: tlaronde@polynum.com To: Pedro Falcato Cc: devel@edk2.groups.io Subject: Re: [edk2-devel] EmulatorPkg: fixes for NetBSD compilation Message-ID: References: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Pedro, Le Mon, Nov 21, 2022 at 10:32:51PM +0000, Pedro Falcato a =E9crit : > On Mon, Nov 21, 2022 at 9:21 PM wrote: >=20 > > 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, >=20 > Again, thanks for the patches. Please send them in the way I kind of > described in my other reply. >=20 > s/u_int/UINT/ >=20 > + off_t DiskSize; > > > I think this off_t is fine, per the other off_t usages, I don't know if= the > maintainers agree. >=20 > > + > > + if (ioctl (Private->fd, DIOCGSECTORSIZE, &BlockSize) =3D=3D 0= ) { > > + Private->Media->BlockSize =3D BlockSize; > > + } > > + > > + if (ioctl (Private->fd, DIOCGMEDIASIZE, &DiskSize) =3D=3D 0) { > > + Private->NumberOfBlocks =3D DivU64x32 (DiskSize, > > (UINT32)BlockSize); > > + Private->Media->LastBlock =3D Private->NumberOfBlocks - 1; > > + } > > + } > > #else > > { > > size_t BlockSize; > > >=20 >=20 > > diff --git a/EmulatorPkg/Unix/Host/Host.c b/EmulatorPkg/Unix/Host/Hos= t.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 !=3D -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 f= unny > that all BSD-derived implementations agree with the fd =3D -1 thing, bu= t 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=20 EDK2?) Best, --=20 Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint =3D 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C