Greg A. Woods wrote:

> Oh, but it does -- the reason for the magic renames and such is so that
> the kernel ABI can change without changing the libc ABI.  How much more
> related can you get?
> 
> If the kernel wants to simultaneously support a prior ABI variation then
> the obvious way to do that is with the /emul feature.

For chrissakes could you _please_ look before sprouting off about the
reasons for why we do symbol renaming?  ~Half the symbol renames we have
are _not_ for kernel ABI changes.

 -  5 to fix some posix braindeadness.
 - 18 for userland-based libc routines
 -  4 set/longjmp related (no idea why)
 - 19 kernel related (signals, sysv shm/sem/msg, stat, vfork)
 -  5 for signal names additions

> Binary compatability is a fine and necessary thing for some purposes,
> but it's not something that any OS vendor should ever have to promise
> accross multiple "major" releases.

I _like_ the fact that I don't need to recompile _every_ third party
application each time I upgrade from release to release.  I like that
very much in fact.  I like that I can grab a binary from an old box and
run it on a new box.  I like that I can try out a new kernel for a while
(with some little lossage from some of the kernel grovellers) before I
decide if I want to keep it.

The reasons for not changing have been described a couple of times now.
Searching for even reasons to justify your stand isn't going to work.

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD CDs, Support and Service:    http://www.wasabisystems.com/