From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 12 17:51:05 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1300D106566C for ; Thu, 12 Feb 2009 17:51:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E21668FC1D for ; Thu, 12 Feb 2009 17:51:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 8691C46B52; Thu, 12 Feb 2009 12:51:04 -0500 (EST) Date: Thu, 12 Feb 2009 17:51:04 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Max Laier In-Reply-To: <200902121717.47841.max@love2party.net> Message-ID: References: <200902121717.47841.max@love2party.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Andrew Brampton Subject: Re: pahole - Finding holes in kernel structs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 17:51:05 -0000 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