On Mar 24, 2006, at 18:01:00, Randy.Dunlap wrote:
Kyle,
Do you have (recorded) or recall any constraints or requirements on
this $subject from Linus or Andrew or others? I mean just basic
big items, like "thou shalt not mix foo and bar".
I'm just looking for the basic parameters of this task.
Well, to a large extent he's actually wisely kind of stayed out of
the flamewars :-D I'm guessing he's hoping that we'll figure
something acceptable out on our own and send him patches without him
having to think about it much. He has said this, though:
On the bigger question of what to do with kernel headers in
general, let's just make one thing clear: the kernel headers are
for the kernel, and big and painful re-organizations that don't
help _existing_ user space are not going to happen.
He's also said this:
On Tue, 30 Nov 2004, Alexandre Oliva wrote:
Then maybe this is the fundamental problem. As long as the kernel
doesn't recognize that an ABI is a contract, rather than an
imposition, kernel developers won't care.
That's a silly analogy. Worse, it's a very flawed analogy.
If you want to use a legal analogy, the ABI is not a contract, it's
a public _license_.
Why? A contract is something that you cannot change unilaterally.
Clearly the kernel _can_ and will change the ABI without asking
every existing program for permission.
In a license, you can always just _expand_ the license eventually.
Maybe you originally licensed for "fly-fishing for trout", and
later you can expand that license to say "you can also catch
crawfish" without impacting your existing licensees.
And exactly as with an ABI, the only thing you can't do is _remove_
rights without getting into trouble.
So get your analogies straight. The kernel ABI is _not_ a contract.
My hope for this is that we can start doing _little_ and clearly
obvious changes that clean up header files. Basically a lot of the
__KERNEL__ definitions need janitorial work. Either they need to be
removed or they need to be put in the right places. Also it seems
like there's a lot of duplication between architectures; for one
example look at all the varieties of FD_SET code in the different
linux/include/asm-*/posix_types.h files. That's one of the areas I'm
trying to clean up into a single linux/fdset.h included from the
pertinent files. Notice how the file forcibly overrides GLIBC; I
think if we can define it as __KABI_FD* and only define the non-
prefixed version in __KERNEL__, then we can provide something that
GLIBC and klibc can get for free, without having to figure out their
own bitmaps. Likewise some of the user-accessible types are uniform
across architectures, and others are haphazardly arrayed, some to be
compatible with other OSes on that architecture, others just because
that's what the arch they copied from used. I'm hoping if I can get
enough small patches flowing, others will join in too and the process
will go easier.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
