From owner-svn-src-head@FreeBSD.ORG Thu Nov 12 16:10:58 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B361F106568D; Thu, 12 Nov 2009 16:10:58 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 6D3308FC2F; Thu, 12 Nov 2009 16:10:58 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 873A66D41B; Thu, 12 Nov 2009 16:10:57 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 5950184513; Thu, 12 Nov 2009 17:10:57 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Robert Watson References: <200911112130.nABLUw9b007768@svn.freebsd.org> <20091112135211.GT64905@hoeg.nl> <86hbsz24sq.fsf@ds4.des.no> Date: Thu, 12 Nov 2009 17:10:57 +0100 In-Reply-To: (Robert Watson's message of "Thu, 12 Nov 2009 15:21:40 +0000 (GMT)") Message-ID: <86zl6rzpta.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, Ed Schouten , svn-src-all@freebsd.org, src-committers@freebsd.org, Xin LI Subject: Re: svn commit: r199201 - in head: contrib/libpcap sbin/ifconfig share/man/man4 sys/kern sys/net sys/sys X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 16:10:58 -0000 Robert Watson writes: > 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. A while ago, I started working on a Perl script that parsed struct declarations. The idea was that we could store a reference copy of the struct layout somewhere, and the script, using its knowledge of alignment and padding rules on different architectures, would calculate the current layout and compare it with the reference layout. I set it aside when I realized how much work it would be to parse function pointers, but we could dodge the issue by always typedef'ing them, e.g. instead of struct sigaction { union { void (*__sa_handler)(int); void (*__sa_sigaction)(int, struct __siginfo *, void *); } __sigaction_u; /* signal handler */ int sa_flags; /* see signal options below */ sigset_t sa_mask; /* signal mask to apply */ }; we'd have typedef void (*__sa_handler_func_ptr)(int); typedef void (*__sa_sigaction_func_ptr)(int, struct __siginfo *, void *); struct sigaction { union { __sa_handler_func_ptr __sa_handler; __sa_sigaction_func_ptr __sa_sigaction; } __sigaction_u; /* signal handler */ int sa_flags; /* see signal options below */ sigset_t sa_mask; /* signal mask to apply */ }; My script understands typedefs, and it should be easy enough to fudge the typedef parsing bit so it knows that __sa_handler_func_ptr and __sa_sigaction_func_ptr are function pointers, which is enough to figure out size and alignment on all architectures we support. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no