From owner-freebsd-hackers Thu Mar 6 11:13: 7 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E17D37B401 for ; Thu, 6 Mar 2003 11:13:03 -0800 (PST) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BA1E43FB1 for ; Thu, 6 Mar 2003 11:13:01 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.5/8.12.5) with ESMTP id h26JCoLZ094866; Fri, 7 Mar 2003 06:12:50 +1100 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.6/8.12.5/Submit) id h26JCnmL094865; Fri, 7 Mar 2003 06:12:49 +1100 (EST) Date: Fri, 7 Mar 2003 06:12:48 +1100 From: Peter Jeremy To: "M. Warner Losh" Cc: hackers@FreeBSD.ORG Subject: Re: Smarter kernel modules? Message-ID: <20030306191248.GD93350@cirb503493.alcatel.com.au> References: <20030305.215901.36360277.imp@bsdimp.com> <20030306075225.GB93350@cirb503493.alcatel.com.au> <20030306.094104.08396502.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030306.094104.08396502.imp@bsdimp.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Mar 06, 2003 at 09:41:04AM -0700, M. Warner Losh wrote: >In message: <20030306075225.GB93350@cirb503493.alcatel.com.au> > Peter Jeremy writes: >: Disadvantages: >: - Needs grunt-work to write the #defines >: - Kernel symbols reported by nm(1) look strange (unless we patch >: binutils to understand our versioning scheme). >: - May present problems to '##' built symbols. > >History has shown that people suck at keeping such a complex scheme up >to date. Also, it versions functions, but not datta structures. Data >strucutre changes are the number 1 cause of ABI breakage we've had >over the last 5 years. I had thought it was fairly simple to maintain, but hadn't really thought through the issue of data structures. If a function or variable definition changes directly, it isn't a great deal of overhead to increment a number elsewhere in a header file that you have to edit anyway. (Though the number of 'bump PORTREVISION please' followups to ports commits suggests that it would be forgotten). If a struct/union/typedef changes, you would need to look through all the references to that type and update them. And if any of the references were another struct/union/typedef, you need to repeat the process. This would be onerous - especially for common types - and therefore neglected. I can't think of any way to easily automate this so I'll withdraw my suggestion. That said, I feel that a single number (or variable name) is too coarse and the "do I need to bump the version" decision is too fuzzy. Unfortunately, I can't think of anything better that wouldn't incur an unacceptable maintenance overhead. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message