* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
[not found] ` <lWLZ.39x.29@gated-at.bofh.it>
@ 2003-08-18 18:54 ` Ihar 'Philips' Filipau
2003-08-18 19:04 ` Jeff Garzik
2003-08-18 20:40 ` Sam Ravnborg
0 siblings, 2 replies; 22+ messages in thread
From: Ihar 'Philips' Filipau @ 2003-08-18 18:54 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel Mailing List
Jeff Garzik wrote:
>>hpa IIRC suggested to create a separate directory:
>>include/abi
>>and then all relevant parts of the kernel should publish their public
>>interface in the abi directory. Would that be usefull?
>
>
> I support include/abi, or some other directory that segregates
> user<->kernel shared headers away from kernel-private headers.
>
> I don't see how that would be auto-generated, though. Only created
> through lots of hard work :)
>
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
2003-08-18 18:54 ` [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined Ihar 'Philips' Filipau
@ 2003-08-18 19:04 ` Jeff Garzik
2003-08-19 12:32 ` Rob Landley
2003-08-18 20:40 ` Sam Ravnborg
1 sibling, 1 reply; 22+ messages in thread
From: Jeff Garzik @ 2003-08-18 19:04 UTC (permalink / raw)
To: Ihar 'Philips' Filipau; +Cc: Linux Kernel Mailing List
On Mon, Aug 18, 2003 at 08:54:21PM +0200, Ihar 'Philips' Filipau wrote:
> Jeff Garzik wrote:
> >>hpa IIRC suggested to create a separate directory:
> >>include/abi
> >>and then all relevant parts of the kernel should publish their public
> >>interface in the abi directory. Would that be usefull?
> >
> >
> >I support include/abi, or some other directory that segregates
> >user<->kernel shared headers away from kernel-private headers.
> >
> >I don't see how that would be auto-generated, though. Only created
> >through lots of hard work :)
> >
>
> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
2003-08-18 18:54 ` [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined Ihar 'Philips' Filipau
2003-08-18 19:04 ` Jeff Garzik
@ 2003-08-18 20:40 ` Sam Ravnborg
1 sibling, 0 replies; 22+ messages in thread
From: Sam Ravnborg @ 2003-08-18 20:40 UTC (permalink / raw)
To: Ihar 'Philips' Filipau; +Cc: Jeff Garzik, Linux Kernel Mailing List
On Mon, Aug 18, 2003 at 08:54:21PM +0200, Ihar 'Philips' Filipau wrote:
>
> There is no need to be a prophet to predict linux/abi being 99%
> symlinks right into include/{asm,linux}.
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
2003-08-18 19:04 ` Jeff Garzik
@ 2003-08-19 12:32 ` Rob Landley
2003-08-19 17:26 ` Jeff Garzik
2003-08-20 23:48 ` Jamie Lokier
0 siblings, 2 replies; 22+ messages in thread
From: Rob Landley @ 2003-08-19 12:32 UTC (permalink / raw)
To: Jeff Garzik, Ihar 'Philips' Filipau; +Cc: Linux Kernel Mailing List
On Monday 18 August 2003 15:04, Jeff Garzik wrote:
> > 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.
Or used directly by uclibc (and linux from scratch) to build the library
against.
> 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
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
2003-08-19 12:32 ` Rob Landley
@ 2003-08-19 17:26 ` Jeff Garzik
2003-08-19 21:38 ` Will uclibc be supported in 2.6? (was Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.) Rob Landley
2003-08-20 1:42 ` [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined Erik Andersen
2003-08-20 23:48 ` Jamie Lokier
1 sibling, 2 replies; 22+ messages in thread
From: Jeff Garzik @ 2003-08-19 17:26 UTC (permalink / raw)
To: Rob Landley; +Cc: Ihar 'Philips' Filipau, Linux Kernel Mailing List
On Tue, Aug 19, 2003 at 08:32:24AM -0400, Rob Landley wrote:
> On Monday 18 August 2003 15:04, Jeff Garzik wrote:
>
> > > 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.
>
> Or used directly by uclibc (and linux from scratch) to build the library
> against.
Yes, this is incorrect.
Kernel developers have been telling people for years, "do not directly
include kernel headers."
> > 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
>
> 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..."
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Will uclibc be supported in 2.6? (was Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.)
2003-08-19 17:26 ` Jeff Garzik
@ 2003-08-19 21:38 ` Rob Landley
2003-08-19 21:47 ` Jeff Garzik
2003-08-20 1:42 ` [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined Erik Andersen
1 sibling, 1 reply; 22+ messages in thread
From: Rob Landley @ 2003-08-19 21:38 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Erik Andersen, Linux Kernel Mailing List
On Tuesday 19 August 2003 13:26, Jeff Garzik wrote:
> On Tue, Aug 19, 2003 at 08:32:24AM -0400, Rob Landley wrote:
> > On Monday 18 August 2003 15:04, Jeff Garzik wrote:
> > > > 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.
> >
> > Or used directly by uclibc (and linux from scratch) to build the library
> > against.
>
> Yes, this is incorrect.
>
> Kernel developers have been telling people for years, "do not directly
> include kernel headers."
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.
> > 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..."
>
> Well, do you expect kernel developers to fix up every libc out there?
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?
> That's what libc maintainers exist for. Distro guys did glibc,
> (glibc-kernheaders) that covers the majority.
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?
> 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...
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. :)
> Jeff
Rob
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Will uclibc be supported in 2.6? (was Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.)
2003-08-19 21:38 ` Will uclibc be supported in 2.6? (was Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.) Rob Landley
@ 2003-08-19 21:47 ` Jeff Garzik
0 siblings, 0 replies; 22+ messages in thread
From: Jeff Garzik @ 2003-08-19 21:47 UTC (permalink / raw)
To: rob; +Cc: Erik Andersen, Linux Kernel Mailing List
Rob Landley wrote:
> 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. :)
That's always been the consensus :)
2.6 is long past the point for major header surgery and breakage.
Jeff
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
2003-08-19 17:26 ` Jeff Garzik
2003-08-19 21:38 ` Will uclibc be supported in 2.6? (was Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.) Rob Landley
@ 2003-08-20 1:42 ` Erik Andersen
1 sibling, 0 replies; 22+ messages in thread
From: Erik Andersen @ 2003-08-20 1:42 UTC (permalink / raw)
To: Jeff Garzik
Cc: Rob Landley, Ihar 'Philips' Filipau, Linux Kernel Mailing List
On Tue Aug 19, 2003 at 01:26:51PM -0400, Jeff Garzik wrote:
> > Or used directly by uclibc (and linux from scratch) to build the library
> > against.
>
> Yes, this is incorrect.
>
> Kernel developers have been telling people for years, "do not directly
> include kernel headers."
<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--
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
2003-08-19 12:32 ` Rob Landley
2003-08-19 17:26 ` Jeff Garzik
@ 2003-08-20 23:48 ` Jamie Lokier
2003-08-21 0:02 ` Jeff Garzik
1 sibling, 1 reply; 22+ messages in thread
From: Jamie Lokier @ 2003-08-20 23:48 UTC (permalink / raw)
To: Rob Landley
Cc: Jeff Garzik, Ihar 'Philips' Filipau, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
2003-08-20 23:48 ` Jamie Lokier
@ 2003-08-21 0:02 ` Jeff Garzik
2003-08-22 0:32 ` Rob Landley
0 siblings, 1 reply; 22+ messages in thread
From: Jeff Garzik @ 2003-08-21 0:02 UTC (permalink / raw)
To: Jamie Lokier
Cc: Rob Landley, Ihar 'Philips' Filipau, Linux Kernel Mailing List
Jamie Lokier wrote:
> 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:
agreed.
> 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?
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
2003-08-21 0:02 ` Jeff Garzik
@ 2003-08-22 0:32 ` Rob Landley
2003-08-22 0:50 ` Chris Friesen
2003-08-22 0:54 ` Jeff Garzik
0 siblings, 2 replies; 22+ messages in thread
From: Rob Landley @ 2003-08-22 0:32 UTC (permalink / raw)
To: Jeff Garzik, Jamie Lokier
Cc: Ihar 'Philips' Filipau, Linux Kernel Mailing List
On Wednesday 20 August 2003 20:02, Jeff Garzik wrote:
> > 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?
...
> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
2003-08-22 0:32 ` Rob Landley
@ 2003-08-22 0:50 ` Chris Friesen
2003-08-22 1:58 ` Rob Landley
2003-08-22 0:54 ` Jeff Garzik
1 sibling, 1 reply; 22+ messages in thread
From: Chris Friesen @ 2003-08-22 0:50 UTC (permalink / raw)
To: rob
Cc: Jeff Garzik, Jamie Lokier, Ihar 'Philips' Filipau,
Linux Kernel Mailing List
Rob Landley wrote:
> On Wednesday 20 August 2003 20:02, Jeff Garzik wrote:
>>>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?
>>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...
> 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...)
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: cfriesen@nortelnetworks.com
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
2003-08-22 0:32 ` Rob Landley
2003-08-22 0:50 ` Chris Friesen
@ 2003-08-22 0:54 ` Jeff Garzik
1 sibling, 0 replies; 22+ messages in thread
From: Jeff Garzik @ 2003-08-22 0:54 UTC (permalink / raw)
To: rob
Cc: Jamie Lokier, Ihar 'Philips' Filipau, Linux Kernel Mailing List
Rob Landley wrote:
> On Wednesday 20 August 2003 20:02, Jeff Garzik wrote:
>>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...
> 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...)
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
2003-08-22 0:50 ` Chris Friesen
@ 2003-08-22 1:58 ` Rob Landley
0 siblings, 0 replies; 22+ messages in thread
From: Rob Landley @ 2003-08-22 1:58 UTC (permalink / raw)
To: Chris Friesen
Cc: Jeff Garzik, Jamie Lokier, Ihar 'Philips' Filipau,
Linux Kernel Mailing List
On Thursday 21 August 2003 20:50, Chris Friesen wrote:
> > 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...)
>
> I thought that this case (including kernel headers) was the whole point
> of the exemption in the COPYING file. Am I missing something?
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...
> Chris
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
2003-08-18 18:08 ` Sam Ravnborg
@ 2003-08-18 18:14 ` Jeff Garzik
0 siblings, 0 replies; 22+ messages in thread
From: Jeff Garzik @ 2003-08-18 18:14 UTC (permalink / raw)
To: Christoph Hellwig, Andries.Brouwer, Dominik.Strasser,
linux-kernel, torvalds
On Mon, Aug 18, 2003 at 08:08:46PM +0200, Sam Ravnborg wrote:
> hpa IIRC suggested to create a separate directory:
> include/abi
> and then all relevant parts of the kernel should publish their public
> interface in the abi directory. Would that be usefull?
I support include/abi, or some other directory that segregates
user<->kernel shared headers away from kernel-private headers.
I don't see how that would be auto-generated, though. Only created
through lots of hard work :)
Jeff
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
2003-08-18 12:24 ` Christoph Hellwig
@ 2003-08-18 18:08 ` Sam Ravnborg
2003-08-18 18:14 ` Jeff Garzik
0 siblings, 1 reply; 22+ messages in thread
From: Sam Ravnborg @ 2003-08-18 18:08 UTC (permalink / raw)
To: Christoph Hellwig, Andries.Brouwer, Dominik.Strasser,
linux-kernel, torvalds
On Mon, Aug 18, 2003 at 01:24:51PM +0100, Christoph Hellwig wrote:
> On Mon, Aug 18, 2003 at 02:19:41PM +0200, Andries.Brouwer@cwi.nl wrote:
> > The right approach is not to break userspace without any kernel
> > benefit whatsoever, but to eliminate the accumulated cruft from
> > scsi.h.
>
> Userspace is supposed to use the glibc <scsi/scsi.h> which is there
> for exactly that reason.
Hi Christoph & others.
Does anyone see a good way to provide a framework to auto-generate
user-space headers from the kernel versions?
hpa IIRC suggested to create a separate directory:
include/abi
and then all relevant parts of the kernel should publish their public
interface in the abi directory. Would that be usefull?
Another way could be to preprocess headerfiles, and store the output
in an abi directory.
Either way it could be good to have a sketch outlined, then
something could be made in 2.7 about this.
Sam
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
2003-08-18 12:19 Andries.Brouwer
2003-08-18 12:24 ` Christoph Hellwig
2003-08-18 15:21 ` Linus Torvalds
@ 2003-08-18 16:13 ` Patrick Mansfield
2 siblings, 0 replies; 22+ messages in thread
From: Patrick Mansfield @ 2003-08-18 16:13 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: Dominik.Strasser, hch, linux-kernel, torvalds
On Mon, Aug 18, 2003 at 02:19:41PM +0200, Andries.Brouwer@cwi.nl wrote:
> For example, this unfortunate discussion started with the u8 in
> ScsiLun, but this concept, introduced in 2.5.11, has been almost
> entirely removed again in 2.5.69, and today only occurs in
> scsi_debug.c. So, we can do
The scsi_debug.c code is there so we can easily test the scsi_scan.c code.
scsi_lun is still used in scsi_scan.c (but not the typedef) when
CONFIG_SCSI_REPORT_LUNS is enabled (as should be the norm).
-- Patrick Mansfield
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
2003-08-18 15:21 ` Linus Torvalds
@ 2003-08-18 15:32 ` Jeff Garzik
0 siblings, 0 replies; 22+ messages in thread
From: Jeff Garzik @ 2003-08-18 15:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andries.Brouwer, Dominik.Strasser, hch, linux-kernel, torvalds
On Mon, Aug 18, 2003 at 08:21:45AM -0700, Linus Torvalds wrote:
>
> On Mon, 18 Aug 2003 Andries.Brouwer@cwi.nl wrote:
> >
> > I see that Linus already applied this, but I am quite unhappy with
> > these changes. Entirely needlessly user space software is broken.
>
> If it's supposed to be exported to user space, it _still_ must not use
> "u_char", since that isn't namespace-clean.
>
> If it needs exporting, it must use "__u8".
Maybe I am biased, but I actually prefer to use the C99 size-specific
types, when code will be used outside the kernel tree... even if that
userland code is entirely Linux-kernel-specific. I try to avoid "__u<size>"
since it's typically a gcc-specific type.
C99 gave us the tools, we should use them :)
Jeff
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
2003-08-18 12:19 Andries.Brouwer
2003-08-18 12:24 ` Christoph Hellwig
@ 2003-08-18 15:21 ` Linus Torvalds
2003-08-18 15:32 ` Jeff Garzik
2003-08-18 16:13 ` Patrick Mansfield
2 siblings, 1 reply; 22+ messages in thread
From: Linus Torvalds @ 2003-08-18 15:21 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: Dominik.Strasser, hch, linux-kernel, torvalds
On Mon, 18 Aug 2003 Andries.Brouwer@cwi.nl wrote:
>
> I see that Linus already applied this, but I am quite unhappy with
> these changes. Entirely needlessly user space software is broken.
If it's supposed to be exported to user space, it _still_ must not use
"u_char", since that isn't namespace-clean.
If it needs exporting, it must use "__u8".
Linus
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
@ 2003-08-18 12:36 Andries.Brouwer
0 siblings, 0 replies; 22+ messages in thread
From: Andries.Brouwer @ 2003-08-18 12:36 UTC (permalink / raw)
To: Andries.Brouwer, hch; +Cc: Dominik.Strasser, linux-kernel, torvalds
From hch@infradead.org Mon Aug 18 14:24:53 2003
On Mon, Aug 18, 2003 at 02:19:41PM +0200, Andries.Brouwer@cwi.nl wrote:
> The right approach is not to break userspace without any kernel
> benefit whatsoever, but to eliminate the accumulated cruft from
> scsi.h.
Userspace is supposed to use the glibc <scsi/scsi.h> which is there
for exactly that reason.
Yes, I already know that you know the mantra.
But you make it sound as if this sad situation is optimal
and never to be changed.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
2003-08-18 12:19 Andries.Brouwer
@ 2003-08-18 12:24 ` Christoph Hellwig
2003-08-18 18:08 ` Sam Ravnborg
2003-08-18 15:21 ` Linus Torvalds
2003-08-18 16:13 ` Patrick Mansfield
2 siblings, 1 reply; 22+ messages in thread
From: Christoph Hellwig @ 2003-08-18 12:24 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: Dominik.Strasser, hch, linux-kernel, torvalds
On Mon, Aug 18, 2003 at 02:19:41PM +0200, Andries.Brouwer@cwi.nl wrote:
> The right approach is not to break userspace without any kernel
> benefit whatsoever, but to eliminate the accumulated cruft from
> scsi.h.
Userspace is supposed to use the glibc <scsi/scsi.h> which is there
for exactly that reason.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.
@ 2003-08-18 12:19 Andries.Brouwer
2003-08-18 12:24 ` Christoph Hellwig
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Andries.Brouwer @ 2003-08-18 12:19 UTC (permalink / raw)
To: Dominik.Strasser, hch; +Cc: linux-kernel, torvalds
> - u_char block_length_hi;
> + u8 block_length_hi;
I see that Linus already applied this, but I am quite unhappy with
these changes. Entirely needlessly user space software is broken.
This file scsi.h was specifically designed for inclusion
in user space programs. (For our favorite mantra: "no inclusion
from user space", see below.) The header still proclaims this:
/*
* This header file contains public constants and structures used by
* the scsi code for linux.
*/
Slowly over time the file has been polluted with random scsi-related
stuff. But now inclusion has been made a lot more difficult -
A strange type u8, and the inclusion of <linux/types.h>, a really
bad idea in user space.
The right approach is not to break userspace without any kernel
benefit whatsoever, but to eliminate the accumulated cruft from
scsi.h.
For example, this unfortunate discussion started with the u8 in
ScsiLun, but this concept, introduced in 2.5.11, has been almost
entirely removed again in 2.5.69, and today only occurs in
scsi_debug.c. So, we can do
diff -u --recursive --new-file -X /linux/dontdiff a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
--- a/drivers/scsi/scsi_debug.c Mon Jul 28 05:39:31 2003
+++ b/drivers/scsi/scsi_debug.c Mon Aug 18 14:16:12 2003
@@ -57,6 +57,13 @@
static const char * scsi_debug_version_str = "Version: 1.70 (20030507)";
+/*
+ * ScsiLun: 8 byte LUN.
+ */
+typedef struct scsi_lun {
+ u8 scsi_lun[8];
+} ScsiLun;
+
/* Additional Sense Code (ASC) used */
#define NO_ADDED_SENSE 0x0
#define UNRECOVERED_READ_ERR 0x11
@@ -65,7 +72,7 @@
#define INVALID_FIELD_IN_CDB 0x24
#define POWERON_RESET 0x29
#define SAVING_PARAMS_UNSUP 0x39
-#define THRESHHOLD_EXCEEDED 0x5d
+#define THRESHOLD_EXCEEDED 0x5d
#define SDEBUG_TAGGED_QUEUING 0 /* 0 | MSG_SIMPLE_TAG | MSG_ORDERED_TAG */
@@ -415,7 +422,7 @@
errsts = resp_read(SCpnt, upper_blk, block, num, devip);
if (inj_recovered && (0 == errsts)) {
mk_sense_buffer(devip, RECOVERED_ERROR,
- THRESHHOLD_EXCEEDED, 0, 18);
+ THRESHOLD_EXCEEDED, 0, 18);
errsts = check_condition_result;
}
break;
@@ -453,7 +460,7 @@
errsts = resp_write(SCpnt, upper_blk, block, num, devip);
if (inj_recovered && (0 == errsts)) {
mk_sense_buffer(devip, RECOVERED_ERROR,
- THRESHHOLD_EXCEEDED, 0, 18);
+ THRESHOLD_EXCEEDED, 0, 18);
errsts = check_condition_result;
}
break;
diff -u --recursive --new-file -X /linux/dontdiff a/include/scsi/scsi.h b/include/scsi/scsi.h
--- a/include/scsi/scsi.h Fri May 30 18:12:58 2003
+++ b/include/scsi/scsi.h Mon Aug 18 14:10:42 2003
@@ -223,13 +223,6 @@
};
/*
- * ScsiLun: 8 byte LUN.
- */
-typedef struct scsi_lun {
- u8 scsi_lun[8];
-} ScsiLun;
-
-/*
* MESSAGE CODES
*/
Andries
[
Yes, about our famous mantra: "User space must not include kernel headers".
I know it. Indeed, I invented it. These days I need not say it so often -
hch is my prophet.
But we should never forget that this is a bad deficiency of Linux,
not something to be proud of. At some point in time we must separate
out headers into the ABI-defining structures and constants, and the
kernel-internal stuff. In the meantime we should try not to pollute
headers that are perfectly good for user space with kernel-specific stuff.
]
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2003-08-22 1:58 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <lRjc.6o4.3@gated-at.bofh.it>
[not found] ` <lRjg.6o4.15@gated-at.bofh.it>
[not found] ` <lWLS.39x.5@gated-at.bofh.it>
[not found] ` <lWLZ.39x.29@gated-at.bofh.it>
2003-08-18 18:54 ` [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined Ihar 'Philips' Filipau
2003-08-18 19:04 ` Jeff Garzik
2003-08-19 12:32 ` Rob Landley
2003-08-19 17:26 ` Jeff Garzik
2003-08-19 21:38 ` Will uclibc be supported in 2.6? (was Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined.) Rob Landley
2003-08-19 21:47 ` Jeff Garzik
2003-08-20 1:42 ` [PATCH] Re: [PATCH] scsi.h uses "u8" which isn't defined Erik Andersen
2003-08-20 23:48 ` Jamie Lokier
2003-08-21 0:02 ` Jeff Garzik
2003-08-22 0:32 ` Rob Landley
2003-08-22 0:50 ` Chris Friesen
2003-08-22 1:58 ` Rob Landley
2003-08-22 0:54 ` Jeff Garzik
2003-08-18 20:40 ` Sam Ravnborg
2003-08-18 12:36 Andries.Brouwer
-- strict thread matches above, loose matches on Subject: below --
2003-08-18 12:19 Andries.Brouwer
2003-08-18 12:24 ` Christoph Hellwig
2003-08-18 18:08 ` Sam Ravnborg
2003-08-18 18:14 ` Jeff Garzik
2003-08-18 15:21 ` Linus Torvalds
2003-08-18 15:32 ` Jeff Garzik
2003-08-18 16:13 ` Patrick Mansfield
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).