scsi.h uses "u8" which isn't defined.

There is no need to be a prophet to predict linux/abi being 99%
symlinks right into include/{asm,linux}.

So it is can turn out to be the same ;-)
It just adds job for mantainers.
(To keep symlinks in correct order ;-)))))

But generally idea is good: keep interface separately from
implementation.

No, the idea is to physically separate the headers.

include/{linux,asm} is currently copied to userspace, hacked a bit, and then shipped as the "glibc-kernheaders" package.

I would rather that the kernel developers directly maintained this interface, by updating headers in include/abi, rather than ad-hoc by distro people.

Jeff

Or used directly by uclibc (and linux from scratch) to build the library against.

Okay, I'd like to ask about the headers thing:

I've got a project using uclibc, and build it myself, currently against the 2.4 headers. What's the plan for 2.6? Everything I've seen on the subject is "using kernel headers directly from userspace is evil, even to build your libc against, but we currently offer no alternative, so go bug your libc maintainer and have THEM do it..."

I'm hoping I've missed something in the months I was off the list this spring, but haven't quite figured out what to search for in the archives yet...

Rob

Yes, this is incorrect.

Kernel developers have been telling people for years, "do not directly include kernel headers."

Well, do you expect kernel developers to fix up every libc out there? That's what libc maintainers exist for. Distro guys did glibc, (glibc-kernheaders) that covers the majority.

In any case, _this thread_ is an attempt to answer your question, "what's the plan?" For 2.6, I don't need include/abi happening. Way too late for that. For 2.7, IMO we need it...

Jeff

In userspace programs, no. But the C library has needed to include the kernel headers because there was nothing else defining the kernel ABI, and there still isn't in the actual kernel tarball.

No, but I do expect the kernel to provide some way to bind to its ABI, and I'd expect the change you're proposing to be to be a 2.7 issue if no alternative has been presented yet for things that currently DO need the kernel headers. (Or is the official word that everybody must install this glibc package to use a 2.6 kernel?)

The new kernel ABI headers mentioned here don't seem to exist yet, yet what I'm hearing is that we're not just supposed to deprecate the old ad-hoc way of doing things, but completely stop using it immediately. What exactly is the benefit of this supposed of to be?

Or are you saying that glibc will be the only C library supported for use with 2.6, and uclibc users should wait until 2.7?

The message everybody quotes from Linus to stop having the asm symlink point into /usr/src/linux came out during the 2.4.0-test series.

http://groups.google.com/groups?selm=linux.kernel.8lop07%242ee%241%40penguin.transmeta.com

Now we're in 2.6.0-test and there's another change coming. Fine. What's the alternative? If the replacement isn't ready, then this is a 2.7 thing rather than what people will actually be doing under 2.6.

Or are you saying linux-kernel should punt and the glibc guys are now going to define the linux kernel ABI for 2.6?

I'm all for doing it in 2.7. I just want to know what I should do for 2.6. If there's a consensus that we're talking about 2.7 and allowing ad-hockery to continue in 2.6, I'll shut up. :)

Rob

That's always been the consensus :)

2.6 is long past the point for major header surgery and breakage.

Jeff

<Kernel developer hat on>

Yes. As a kernel developer I regularly tell people to make their own private copy of the bits of kernel headers they need, to prevent breakage when random bits in the kernel headers change. I can't begin to count the number of applications I have fixed by removing some kernel headers and then copying in the definition of some random struct, adding a few ioctl defines, and then changing everything to use types from stdint.h rather than the kernel's internal typing.

I have also long maintained that this is incredibly stupid.... When I wrote the cdrom.h header file, for example, I wrote it to define the interface which user space would use when talking to the kernel. I _designed_ that header file to be directly used by user space, since that is the one and only spot that contains all the relevant knowledge needed to interact with the kernel's cdrom driver. I mean, how else would user space know what to do? It is silly there needs to be N copies of the header file defining this interface for N applications... The fact the kernel has mingled its internal interfaces and its external interfaces is a serious and ugly blemish.

<uClibc maintainer hat on>

Not including kernel headers in user space is of course perfect advice for your average piece of user space. This is _not_ currently a reasonable request for a C library because the kernel folk have not yet provided a reasonable alternative. Looked at glibc recently? Just like uClibc, it determines the ABI of the kernel against which it is compiled (in the case of glibc, via the --with-headers configure option). Distros such as RedHat and Debian provide kernel-headers packages against which C libraries are compiled. Guess what those contain? Kernel headers. Kernel headers which are used by user space because the kernel folk have been too damn lazy to provide something better.

That said, for uClibc I have begun the process of eliminating the dependence on kernel headers for random structs. I now have arch specific headers such as "kernel_stat.h", mainly since the kernel headers are too inconsistant between architectures to be even remotely usable. But as others have noted, extracting and sanitizing the entire kernel ABI is a huge amount of work and I am nowhere close to done.

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Well, I've done quite a bit of

	#ifdef __i386__
	#define __NR_futex	240
	#elif defined (__alpha__)
	#define __NR_futex	394
	#elif defined (__mips__)
	... etc. ...
	#endif

In order to distribute programs which compile with a distro's libc but will take advantage of features in later kernels when run on them.

That's really unpleasant. So, in revenge, here's an annoying question:

If userspace applications are ultimately compiled using Linux header files, indirectly included via Glibc or some other libc, and the kernel header files are GPL (version 2 only; not LGPL or any later GPL), isn't distributing those binary applications a gross violation of the GPL in some cases?

-- Jamie

agreed.

It's come up before, so it's not necessarily an original, annoying question ;-)

My non-lawyer guess would be, the structures and defines are required for Linux interoperability; that may be a factor. static inline functions in headers, i.e. real code, is another matter too.

One way or another (direct inclusion, or via glibc-kernheaders pkg) the headers today are GPL'd not LGPL'd... so I suppose it remains the realm of lawyers...

IANAL,

Jeff

...

So I take it one of the goals of cleaned and pressed kernel-ABI headers for 2.7 would be to have them distributable under LGPL? (Just trying to be explicit, here...)

Rob

I thought that this case (including kernel headers) was the whole point of the exemption in the COPYING file. Am I missing something?

Chris

Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: [email protected]

It's legal contortionism, and it might leave some dangling technicalities.

The Linux kernel is licensed under the GPL. Linus's statements are just his interpretation of what consitutes a derived work, and hence the scope of the GPL. (So it's PROBABLY not an incompatable additional license clause thingy that makes it "not GPL" for the purpose of linking GPL code to it.) But lots of other people's code has been combined with Linus's, and they might consider their code under the straight GPL (sans adendum).

Whether Linus's word is final on this matter is up to a judge. (It PROBABLY is, since he's the project maintainer and the project license is "GPL plus this memo about derived work interpretation", and anybody who contributes to the project without knowing that is Not Paying Attention. Certainly all the contributors have had warning about this when submitting code to Linux for more than the past 3 years (which might be the statute of limitations, depending on who you ask), so for code THEY contributed we should be okay. The corner case is when somebody other than the code's author lifts code from other GPL projects and puts it in Linux, but then again that's not amazingly common either since how many other GPL operating system kernels do you see out there? (And even then, if Linus's guide is an interpretation about the scope of derived works rather than a license adendum, then it may not actually be incompatable with the GPL, but who knows...)

All this is hair splitting, but we've all seen what happens when companies with more lawyers than sense decide they have no profitable business model to live for, buy a bunch of liquor, and pledge to take their friends out with them. Nobody as ornery and stupid as SCO has sued over this fine point yet to give us a straw man to shoot down, so the issue hasn't been resolved in court yet. I can't see SCO suing to EXTEND the reach of the GPL right now, so it's not an immediate pressing issue. And if it did, Linus would be the main wronged party, who A) doesn't WANT damages, B) would be thrilled to settle out of court for a gift certificate to Wendy's or something, C) could obviously whip out a kernel-ABI package in an afternoon to remedy it, D) would probably rip out the contributions of any author who made a major stink about never taking even a typo correction patch from them again.

But it would be nice to clean it up beforehand anyway. The LGPL exists for a reason...

(And predicting SCO's actions based on what's good for their continued financial or legal health would not have been a particularly accurate prognostication technique over the past six months...)

This whole issue is about on the level of "do not remove this mattress tag", by the way. That's why people have been so complacent about it so far...

Rob

P.S. Even if I was a lawyer, which I'm not, you'd have to be insane to take legal advice from a stranger on the internet who you hadn't even paid a retainer to. If you really care, go find a lawyer who understands intellectual property as applied to software, and the GPL specifically, and ask them. (This may take some time. I can think of four in the whole of north america, and two of them have asked ME for a second opinion...)

P.P.S. Don't even ASK about the "restricted to V2, not later versions" thing. I'm just not going there right now...

P.P.P.S. If you're REALLY bored, might I suggest getting a copy of "Legal Battles that Shaped the Computer Industry". (It's dry reading, but where else are you going to find out about a lawsuit between AT&T and Franklin Ace that probably helped lead to both AT&T's commercialization of Unix and the formation of the Free Software Foundation? Of course you have to supply half the context yourself...) It's reviewed here:
http://www.hmdc.harvard.edu/micah_altman/papers/battles.pdf

Changing the status quo involves lots of pain: querying every author if it's ok to change the license, and dealing with authors that don't want to change the license, or, rewriting the headers under a new license, etc.

I think it's best to do what we can from the technical perspective.

Jeff

Symlinks will not be included in the vanilla kernel source. But if several files just had to be moved that would be a good start.

With potential wrappers in include/linux obviously.

Sam