On Thu, Mar 06, 2003 at 09:41:04AM -0700, M. Warner Losh wrote: >In message: <[EMAIL PROTECTED]> > Peter Jeremy <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
