Date: Thu, 12 Feb 2009 17:51:04 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Max Laier <max@love2party.net> Cc: freebsd-hackers@freebsd.org, Andrew Brampton <brampton+freebsd-hackers@gmail.com> Subject: Re: pahole - Finding holes in kernel structs Message-ID: <alpine.BSF.2.00.0902121748180.2205@fledge.watson.org> In-Reply-To: <200902121717.47841.max@love2party.net> References: <d41814900902120608i4b54c86fp9f565bbeead5a476@mail.gmail.com> <200902121717.47841.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 12 Feb 2009, Max Laier wrote: > That's the tricky part. Rearranging the structs itself is not that > difficult, but identifying which should be rearranged and if, how ... that's > the problem. The fact that gaps might be different for 64 vs. 32 bit > architectures has already been mentioned. > > In addition one needs to keep in mind that changing a struct layout is a ABI > change. So if we do identify structs that we want to change we should do > them all at once to keep the different versions down to a minimum. Leaving aside the potential memory savings, etc, another potential use for a tool like this is actually in ABI monitoring and maintenance. I.e., run a tool that generates a description of the structure ABI of the kernel and user interfaces of the system, then run it intermittently to detect and report changes, perhaps correlated with symbol version information, etc. Right now we discover ABI changes in three ways: a developer changing the ABI realizes it has changed and (probably) deals with it, a developer reviews changes later and finds it, or a user finds it the hardware way due to application crashes, data loss, etc. Mechanizing tracking of API signatures, structure layout, etc, would help make all of this a lot more deterministic. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0902121748180.2205>