Date: Thu, 12 Nov 2009 15:21:40 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no> Cc: svn-src-head@freebsd.org, Ed Schouten <ed@80386.nl>, svn-src-all@freebsd.org, src-committers@freebsd.org, Xin LI <delphij@FreeBSD.org> Subject: Re: svn commit: r199201 - in head: contrib/libpcap sbin/ifconfig share/man/man4 sys/kern sys/net sys/sys Message-ID: <alpine.BSF.2.00.0911121518460.11129@fledge.watson.org> In-Reply-To: <86hbsz24sq.fsf@ds4.des.no> References: <200911112130.nABLUw9b007768@svn.freebsd.org> <20091112135211.GT64905@hoeg.nl> <86hbsz24sq.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-128957440-1258039300=:11129 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 12 Nov 2009, Dag-Erling Smørgrav wrote: >> So there used to be four chars in a row here (between if_description and >> if_cspare). Are you sure moving the pointer in between doesn't increase the >> structure size? > > I can guarantee you that it does. On i386, for instance, there are now > three bytes of implicit padding between if_alloctype and if_description, and > one more between if_cspare and if_pspare, so struct ifnet has grown by four > bytes. > > We should have CASSERTs for sizeof(struct ifnet) and other structs we really > care about. We care less about ifnet than we used to, because ifnet is now allocated by the kernel rather than drivers. However, if we want to take our KPI/KBI more seriously, then CTASSERTs on other "public" kernel structures might well be a good idea. On the other hand, CTASSERT errors on build are almost impervious to mortal comprehension (if you haven't seen them before, they make little sense to the reader), and will make it more difficult for people hacking on our kernel to do so casually. Some sort of other static checker might make more sense, and perhaps allow us to do more intelligent checking that just "total size" -- we'd also like to detect rearrangement of sensitive structs that would be size-preserving. Robert --621616949-128957440-1258039300=:11129--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0911121518460.11129>