Date: Thu, 12 Nov 2009 10:08:49 -0600 From: Brooks Davis <brooks@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Ed Schouten <ed@80386.nl>, src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, Xin LI <delphij@FreeBSD.org>, svn-src-head@FreeBSD.org, Dag-Erling Sm?rgrav <des@des.no> Subject: Re: svn commit: r199201 - in head: contrib/libpcap sbin/ifconfig share/man/man4 sys/kern sys/net sys/sys Message-ID: <20091112160849.GB65026@lor.one-eyed-alien.net> In-Reply-To: <alpine.BSF.2.00.0911121518460.11129@fledge.watson.org> References: <200911112130.nABLUw9b007768@svn.freebsd.org> <20091112135211.GT64905@hoeg.nl> <86hbsz24sq.fsf@ds4.des.no> <alpine.BSF.2.00.0911121518460.11129@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--ZfOjI3PrQbgiZnxM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 12, 2009 at 03:21:40PM +0000, Robert Watson wrote: >=20 > On Thu, 12 Nov 2009, Dag-Erling Sm??rgrav wrote: >=20 >>> So there used to be four chars in a row here (between if_description an= d=20 >>> if_cspare). Are you sure moving the pointer in between doesn't increase= =20 >>> the structure size? >>=20 >> I can guarantee you that it does. On i386, for instance, there are now= =20 >> three bytes of implicit padding between if_alloctype and if_description,= =20 >> and one more between if_cspare and if_pspare, so struct ifnet has grown = by=20 >> four bytes. >>=20 >> We should have CASSERTs for sizeof(struct ifnet) and other structs we=20 >> really care about. >=20 > We care less about ifnet than we used to, because ifnet is now allocated = by=20 > the kernel rather than drivers. However, if we want to take our KPI/KBI= =20 > more seriously, then CTASSERTs on other "public" kernel structures might= =20 > well be a good idea. On the other hand, CTASSERT errors on build are=20 > almost impervious to mortal comprehension (if you haven't seen them befor= e,=20 > they make little sense to the reader), and will make it more difficult fo= r=20 > people hacking on our kernel to do so casually. Some sort of other stati= c=20 > checker might make more sense, and perhaps allow us to do more intelligen= t=20 > checking that just "total size" -- we'd also like to detect rearrangement= =20 > of sensitive structs that would be size-preserving. In this specific case, we should remove all the spare pointers since they don't really add value. The only rule should be that when you MFC you have to add to the end rather than inserting in the strictly logical location. -- Brooks --ZfOjI3PrQbgiZnxM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFK/DMRXY6L6fI4GtQRAuGsAJ9e65J9g3HLfajdU56nCRlRNU1kNQCfZACW 8K9lsTimLCfdrl3mG7N+x6A= =QQT0 -----END PGP SIGNATURE----- --ZfOjI3PrQbgiZnxM--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091112160849.GB65026>