Subject: Re: stdio FILE extension
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Simon Burge <firstname.lastname@example.org>
Date: 10/17/2001 17:34:20
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 Burge <email@example.com>
NetBSD CDs, Support and Service: http://www.wasabisystems.com/