Date: Fri, 7 Mar 2003 06:12:48 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: "M. Warner Losh" <imp@bsdimp.com> Cc: hackers@FreeBSD.ORG Subject: Re: Smarter kernel modules? Message-ID: <20030306191248.GD93350@cirb503493.alcatel.com.au> In-Reply-To: <20030306.094104.08396502.imp@bsdimp.com> References: <20030305.215901.36360277.imp@bsdimp.com> <20030306075225.GB93350@cirb503493.alcatel.com.au> <20030306.094104.08396502.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 06, 2003 at 09:41:04AM -0700, M. Warner Losh wrote: >In message: <20030306075225.GB93350@cirb503493.alcatel.com.au> > Peter Jeremy <peterjeremy@optushome.com.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030306191248.GD93350>