Re: Kernel includefile bug not fixed after a year :-(

Re: Kernel includefile bug not fixed after a year :-(

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]

>From davem@redhat.com  Tue Sep 30 14:28:23 2003

>On Tue, 30 Sep 2003 14:06:29 +0200
>Jens Axboe <axboe@suse.de> wrote:

>> I asked you one simple question: when did the kernel/user interface
>> break, and how?

>I'll answer for him, about 20 or 30 times during IPSEC development.
>It's still possible this could change even some more before 2.6.0
>final is released if a large enough bug in the IPSEC socket APIs are
>found in time.

There is a simple rule of thumb:

If the kernel code is not even ready for testing: don't inlcude it
in external releases.

If it makes sense to test the code and it uses new interfaces then you
need to make the interfaces available to potential users of the interface.
If the interface is going to change then the user should be informed about the
fact, but you yould need the kernel interface include files.

glibc exports own interaces and for this reason needs to supply own include 
files. I see no reason however that glibc should deal with include files that
do not even affect glibc code. This is true for most ioctl()s,
it is definitely true for the SCSI related ioctl()s.



Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: Kernel includefile bug not fixed after a year :-(

[Albert Cahalan]

Joerg Schilling writes:

>> Also Joerg, now that I have your attention: There is a bug
>> somewhere so that if I set the kernel HZ to 400, recompile
>> everything including `cdrecord`, I can no longer record a CD.
>> I think that somewhere, somebody is using a raw jiffie-count
>> instead of multiplying by HZ in the time-out code. I've check
>> through all the SCSI stuff, and I use SCSI disks exclusively.
>> I think something in your code needs fixing. This is for kernel
>> version 2.4.22
>
> Cdrecord and pther programs too includes <sys/param.h>

If that's a kernel header, you have a bug.

> If you change HZ in the kernel include files and recompile
> your problems suffer from the same sort of inconsistencies
> that have been the reason for my initial mail.
>
> If Linux likes to support changes to HZ, then it needs to
> support POSIX interfaces. On Solaris, sys/param.h looks this way:
>
> #define        HZ              ((clock_t)_sysconf(_SC_CLK_TCK))

On a Linux 2.4.xx system and above, you do this:

/////////////////////////////////////////////////////
#ifndef AT_CLKTCK
#define AT_CLKTCK       17    // frequency of times()
#endif

#define NOTE_NOT_FOUND 42

//extern char** environ;  // if _GNU_SOURCE not defined

// for ELF executables, notes are pushed before environment and args
// (Portable too! This even works on PA_RISC for some reason.)
static unsigned long find_elf_note(unsigned long findme){
  unsigned long *ep = (unsigned long *)environ;
  while(*ep++);
  while(*ep){
    if(ep[0]==findme) return ep[1];
    ep+=2;
  }
  return NOTE_NOT_FOUND;
}

// ...

Hertz = find_elf_note(AT_CLKTCK);

/////////////////////////////////////////////////////

Don't trust any _sysconf() junk. It's broken.

> You may even change HZ on a running Solaris system.... the
> only programs that are affected may be the ones that have
> timeouts while the change has been done.

Cute. It's bloat though, because it turns constant
expressions into variable ones.

> The problem is that the timeouts in the SCSI interface are
> based on HZ rather than being abstract from kernel internals.

That's a bug. They should be in terms of USER_HZ,
milliseconds, centiseconds, microseconds, or nanoseconds.
Pick something good and make a patch.

Re: Kernel includefile bug not fixed after a year :-(

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1626 bytes --]

>From root@chaos.analogic.com  Tue Sep 30 14:21:07 2003

>Reply is not on the list.

I added the list because this is another problem that need fixiong inside the 
kernel.

>Also Joerg, now that I have your attention: There is a bug
>somewhere so that if I set the kernel HZ to 400, recompile
>everything including `cdrecord`, I can no longer record a CD.
>I think that somewhere, somebody is using a raw jiffie-count
>instead of multiplying by HZ in the time-out code. I've check
>through all the SCSI stuff, and I use SCSI disks exclusively.
>I think something in your code needs fixing. This is for kernel
>version 2.4.22


Cdrecord and pther programs too includes <sys/param.h>

If you change HZ in the kernel include files and recompile your problems
suffer from the same sort of inconsistencies that have been the reason for
my initial mail.

If Linux likes to support changes to HZ, then it needs to support POSIX
interfaces. On Solaris, sys/param.h looks this way:

#define        HZ              ((clock_t)_sysconf(_SC_CLK_TCK))

You may even change HZ on a running Solaris system.... the only programs that
are affected may be the ones that have timeouts while the change has been done.

The problem is that the timeouts in the SCSI interface are based on HZ rather
than being abstract from kernel internals.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: Kernel includefile bug not fixed after a year :-(

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3688 bytes --]

>From axboe@suse.de  Tue Sep 30 14:06:29 2003

>> >> >/usr/include/scsi/scsi.h looks fine on my system, probably also on
>> >> >yours. You should not include kernel headers in your user space program.
>> >> 
>> >> Looks like you did not understand the background :-(
>> 
>> >I think I do.
>> 
>> Sorry, but you just verified that you don't :-(

>No, you continue to show you don't understand why you should not include
>kernel headers in user space.

You continue to verify that you don't understand how kernel <-> user level
interfaces are used by user level programs. 

The Linux kernel constantly adds new interfaces or changes old ones.
A user program that is going to use these interfaces _needs_ to include
up-to-date kernel include interface definitions.

If the kernel is not integral part of the whole system (which is definitely true
for a Linux based system) user level programs _need_ to include the kernel 
include files from the same snapshot as the kernel.

The basic concept of hiding kernel (only) data structures from user level 
programs is to put them between #ifdef __KERNEL__ #endif.
It is definitely typically not done by editing kernel level files later and by 
creating a different set (and thus potentially out of sync) of include files.

If you don't understand this bacic concept, then it makes not sense to continue
this discussion :-(

>> >> In order to use kernel interfaces you _need_ to include kernel include
>> >> files.
>> 
>> >False. You need to include the glibc kernel headers.
>> 
>> 
>> False: as glibc kernel headers are not part of the kernel distribution.

>How is that an argument? By your logic, you need one huge package with
>basically everything in it, how else do you know your application works
>with that given kernel?

Did you ever do a 'du' on /usr/include/sys and compare with 'du' on
/usr/src/linux? It seems that not :-(

A kernel source that uses internal include files that deviate (how ever) 
from the ones that are present in /usr/include/sys/ needs to include include
files that are consistent for user level use. The _way_ how you do this does 
not matter!

If you decide to have a different set of hand edited files, create them
but _always_ include them with the Linux kernel sources....

However, it is easily to understand that it makes more sense to just keep
the internal include files from the Linux kernel constsistent.
The current include files inside the Linux kernel definitely are not
consistent.


>I asked you one simple question: when did the kernel/user interface
>break, and how? You happily chose to ignore that. A pity, since that
>would be the core of your argument.

Well, this has been discussed several times and it would make sense if you
try to e.g. search the Linux kernel mailing lists or the cdrecording mailing 
lists.....

Search for failing cdrecord compilations and runs that are caused from Linux
kernel changes ....

I don't like that an important discussion about Linux include files to be
converted into rants....so let us stay with the topic.

I also told you that the addition of a single feature to an interface
does not make sense as long as user level programs cannot use them. If you like
to use them you need up to date include files for the kernel interfaces.

...please don't try to tell me that Linux never adds new features that
result at least in extended interfaces...

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: Kernel includefile bug not fixed after a year :-(

[Tomas Szepe]

> [schilling@fokus.fraunhofer.de]
> 
> You continue to verify that you don't understand how kernel <-> user level
> interfaces are used by user level programs. 

No.  The problem is that you chose to ignore what Linux developers had
had to tell you and so managed to annoy the hell out of everyone involved.

Instead, you could have sent a simple patch and everything would have
been swell.

You are not a good diplomat, Joerg.

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: Kernel includefile bug not fixed after a year :-(

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2221 bytes --]


>From axboe@suse.de  Tue Sep 30 13:54:12 2003

>> >> Is there no interest in user applications for kernel features or is there just
>> >> no kernel maintainer left over who makes the needed work?
>> 
>> >/usr/include/scsi/scsi.h looks fine on my system, probably also on
>> >yours. You should not include kernel headers in your user space program.
>> 
>> Looks like you did not understand the background :-(

>I think I do.

Sorry, but you just verified that you don't :-(

>> In order to use kernel interfaces you _need_ to include kernel include
>> files.

>False. You need to include the glibc kernel headers.


False: as glibc kernel headers are not part of the kernel distribution.

>> This is in particular true as long as we are talking about
>> beta/testing kernels.
>> 
>> 
>> Background: on homogeneous platforms like e.g. Solaris or FreeBSD
>> which are maintained and distributed as whole, an _enduser_ should
>> include files from /usr/include only. 
>> 
>> 	This is not even true for people who do Solaris or FreeBSD
>> 	kernel development and like to test new features with user level
>> 	programs.  It is definitely not true for compilations against
>> 	Linux kernel interfaces.
>> 
>> Linux is not a homogeneous system. There is a separately developed
>> kernel and a separate base user level system. People often install a
>> newer kernel and need to recompile software because the kernel/user
>> interfaces are not stable between different Linux releases.

>That's a pretty bold claim, when did the kernel/user interface break? A
>lot of care is usually taken to ensure that this does not happen.

>This subject has been debated to death lots of times before, I'm sure
>the archives are more detailed and enlightening that I am.

If these debates have not been done in a serious way, or people without
the needed kernel development background knowledge did decide, these
debates are just void.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: Kernel includefile bug not fixed after a year :-(

[Jens Axboe]

On Tue, Sep 30 2003, Joerg Schilling wrote:
> 
> >From axboe@suse.de  Tue Sep 30 13:54:12 2003
> 
> >> >> Is there no interest in user applications for kernel features or is there just
> >> >> no kernel maintainer left over who makes the needed work?
> >> 
> >> >/usr/include/scsi/scsi.h looks fine on my system, probably also on
> >> >yours. You should not include kernel headers in your user space program.
> >> 
> >> Looks like you did not understand the background :-(
> 
> >I think I do.
> 
> Sorry, but you just verified that you don't :-(

No, you continue to show you don't understand why you should not include
kernel headers in user space.

> >> In order to use kernel interfaces you _need_ to include kernel include
> >> files.
> 
> >False. You need to include the glibc kernel headers.
> 
> 
> False: as glibc kernel headers are not part of the kernel distribution.

How is that an argument? By your logic, you need one huge package with
basically everything in it, how else do you know your application works
with that given kernel?

I asked you one simple question: when did the kernel/user interface
break, and how? You happily chose to ignore that. A pity, since that
would be the core of your argument.

I'm not saying that situation _never_ happened, but it is an extremely
rare event and usually only happens for a very good reason. When did you
last need to recompile a program because you upgraded your kernel?

> >> This is in particular true as long as we are talking about
> >> beta/testing kernels.
> >> 
> >> 
> >> Background: on homogeneous platforms like e.g. Solaris or FreeBSD
> >> which are maintained and distributed as whole, an _enduser_ should
> >> include files from /usr/include only. 
> >> 
> >> 	This is not even true for people who do Solaris or FreeBSD
> >> 	kernel development and like to test new features with user level
> >> 	programs.  It is definitely not true for compilations against
> >> 	Linux kernel interfaces.
> >> 
> >> Linux is not a homogeneous system. There is a separately developed
> >> kernel and a separate base user level system. People often install a
> >> newer kernel and need to recompile software because the kernel/user
> >> interfaces are not stable between different Linux releases.
> 
> >That's a pretty bold claim, when did the kernel/user interface break? A
> >lot of care is usually taken to ensure that this does not happen.
> 
> >This subject has been debated to death lots of times before, I'm sure
> >the archives are more detailed and enlightening that I am.
> 
> If these debates have not been done in a serious way, or people without
> the needed kernel development background knowledge did decide, these
> debates are just void.

Did you search and find these debates? Or are you just assuming you know
better?

-- 
Jens Axboe

Re: Kernel includefile bug not fixed after a year :-(

[David S. Miller]

On Tue, 30 Sep 2003 14:06:29 +0200
Jens Axboe <axboe@suse.de> wrote:

> I asked you one simple question: when did the kernel/user interface
> break, and how?

I'll answer for him, about 20 or 30 times during IPSEC development.
It's still possible this could change even some more before 2.6.0
final is released if a large enough bug in the IPSEC socket APIs are
found in time.

But that's not the important issue, the important issue is that
a huge number of kernel API interfaces have no equivalent in
whatever you consider to be "user usable non-kernel headers".

Find me the API defines for the IPSEC configuration socket interfaces
in a header file that you think users should be allowed to include.

You won't find it Jens, and that's why it drives me nuts when people
spit out the "no kernel headers" mantra.  Often it simply must be
done as a matter of practicality.

Re: Kernel includefile bug not fixed after a year :-(

[Jens Axboe]

On Tue, Sep 30 2003, David S. Miller wrote:
> On Tue, 30 Sep 2003 14:06:29 +0200
> Jens Axboe <axboe@suse.de> wrote:
> 
> > I asked you one simple question: when did the kernel/user interface
> > break, and how?
> 
> I'll answer for him, about 20 or 30 times during IPSEC development.

Sorry dave, that's a lame example. The fact that your (and who else did
ipsec) code/interface wasn't mature and thus changed interfaces in the
development series is perfectly acceptable in my book. But it sure as
hell must not happen between 2.4.20 and 2.4.21, for instance.

> It's still possible this could change even some more before 2.6.0
> final is released if a large enough bug in the IPSEC socket APIs are
> found in time.

As I wrote in the mail to Joerg, it should basically never happen unless
there's a damn good reason to. -testX series is still sort-of
development, so I'd accept such a change right now.

> But that's not the important issue, the important issue is that
> a huge number of kernel API interfaces have no equivalent in
> whatever you consider to be "user usable non-kernel headers".

And why is that?

> Find me the API defines for the IPSEC configuration socket interfaces
> in a header file that you think users should be allowed to include.

I wont go chasing your code, sorry. I'm sure you could come up with
that, if no usable interface exists how on earth are you expected to use
it from user space?

> You won't find it Jens, and that's why it drives me nuts when people
> spit out the "no kernel headers" mantra.  Often it simply must be
> done as a matter of practicality.

This discussion has spun off on a tangent. Joerg asked why that breakage
has not been fixed, I point out why that is so. I usually make sure that
whatever headers I mess with _do_ work from user space (cdrom.h is a
long nasty example), however it's never been guarenteed that this would
be the case for all kernel headers. Quite the opposite, in fact. And
back to my previous mail to you: if you do, be prepared to fix the
breakage yourself.

-- 
Jens Axboe

Re: Kernel includefile bug not fixed after a year :-(

[Krzysztof Halasa]

Jens Axboe <axboe@suse.de> writes:

> This discussion has spun off on a tangent. Joerg asked why that breakage
> has not been fixed, I point out why that is so. I usually make sure that
> whatever headers I mess with _do_ work from user space (cdrom.h is a
> long nasty example), however it's never been guarenteed that this would
> be the case for all kernel headers.

Then we should fix the broken headers so that it is guaranteed.
That's quite trivial, isn't it?

I don't really understand why it's that important to duplicate
definitions from kernel headers in libc ones.
IMHO glibc headers should include kernel headers instead of defining
things which are already defined by the kernel and used on kernel-user
interface.

Duplicate definitions should IMHO be removed from glibc headers.
-- 
Krzysztof Halasa, B*FH

Re: Kernel includefile bug not fixed after a year :-(

[Sandy Harris]

David S. Miller wrote:

>>... when did the kernel/user interface break, and how?
> 
> 
> I'll answer for him, about 20 or 30 times during IPSEC development.
> ...

Natural enough.

> But that's not the important issue, the important issue is that
> a huge number of kernel API interfaces have no equivalent in
> whatever you consider to be "user usable non-kernel headers".
> 
> Find me the API defines for the IPSEC configuration socket interfaces
> in a header file that you think users should be allowed to include.
> 
> You won't find it Jens,

That is, you and the other IPsec developers did not create it.
I wonder why not.

 From my rather naive perspective, I would think providing header
files for whatever interface you provide is part of the job. Of
course they'd have to be user-includable and documented at least
in man pages.

I suspect I am missing something here. What?

> and that's why it drives me nuts when people
> spit out the "no kernel headers" mantra.  Often it simply must be
> done as a matter of practicality.

Re: Kernel includefile bug not fixed after a year :-(

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]

>From axboe@suse.de  Tue Sep 30 13:05:18 2003

>On Tue, Sep 30 2003, Joerg Schilling wrote:
>> A year after I did report this inconsistency, it is still not fixed
>> 
>> If include/scsi/scsi.h is included without __KERNEL__ #defined, then this
>> error message apears.
>> 
>> /usr/src/linux/include/scsi/scsi.h:172: parse error before "u8"
>> /usr/src/linux/include/scsi/scsi.h:172: warning: no semicolon at end of struct 
>> or union
>> /usr/src/linux/include/scsi/scsi.h:173: warning: data definition has no type or 
>> storage class
>> 
>> Is there no interest in user applications for kernel features or is there just
>> no kernel maintainer left over who makes the needed work?

>/usr/include/scsi/scsi.h looks fine on my system, probably also on
>yours. You should not include kernel headers in your user space program.

Looks like you did not understand the background :-(

In order to use kernel interfaces you _need_ to include kernel include files.

This is in particular true as long as we are talking about beta/testing kernels.


Background: on homogeneous platforms like e.g. Solaris or FreeBSD which are
	maintained and distributed as whole, an _enduser_ should include
	files from /usr/include only. 

	This is not even true for people who do Solaris or FreeBSD kernel 
	development and like to test new features with user level programs.
	It is definitely not true for compilations against Linux kernel
	interfaces.

Linux is not a homogeneous system. There is a separately developed kernel and 
a separate base user level system. People often install a newer kernel and need 
to recompile software because the kernel/user interfaces are not stable between
different Linux releases.

These people need to compile against the recent Linux kernel include files if
they use Linux kernel <-> user level interfaces.

-	... why do you believe that #ifdef __KERNEL__ kernel do exist inside 
	Linux kernel include files if they are not intended for user level 
	programs?

-	How should user level program that depend on kernel interfaces be 
	compiled if not by using kernel include files?


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: Kernel includefile bug not fixed after a year :-(

[Jens Axboe]

On Tue, Sep 30 2003, Joerg Schilling wrote:
> >From axboe@suse.de  Tue Sep 30 13:05:18 2003
> 
> >On Tue, Sep 30 2003, Joerg Schilling wrote:
> >> A year after I did report this inconsistency, it is still not fixed
> >> 
> >> If include/scsi/scsi.h is included without __KERNEL__ #defined, then this
> >> error message apears.
> >> 
> >> /usr/src/linux/include/scsi/scsi.h:172: parse error before "u8"
> >> /usr/src/linux/include/scsi/scsi.h:172: warning: no semicolon at end of struct 
> >> or union
> >> /usr/src/linux/include/scsi/scsi.h:173: warning: data definition has no type or 
> >> storage class
> >> 
> >> Is there no interest in user applications for kernel features or is there just
> >> no kernel maintainer left over who makes the needed work?
> 
> >/usr/include/scsi/scsi.h looks fine on my system, probably also on
> >yours. You should not include kernel headers in your user space program.
> 
> Looks like you did not understand the background :-(

I think I do.

> In order to use kernel interfaces you _need_ to include kernel include
> files.

False. You need to include the glibc kernel headers.

> This is in particular true as long as we are talking about
> beta/testing kernels.
> 
> 
> Background: on homogeneous platforms like e.g. Solaris or FreeBSD
> which are maintained and distributed as whole, an _enduser_ should
> include files from /usr/include only. 
> 
> 	This is not even true for people who do Solaris or FreeBSD
> 	kernel development and like to test new features with user level
> 	programs.  It is definitely not true for compilations against
> 	Linux kernel interfaces.
> 
> Linux is not a homogeneous system. There is a separately developed
> kernel and a separate base user level system. People often install a
> newer kernel and need to recompile software because the kernel/user
> interfaces are not stable between different Linux releases.

That's a pretty bold claim, when did the kernel/user interface break? A
lot of care is usually taken to ensure that this does not happen.

This subject has been debated to death lots of times before, I'm sure
the archives are more detailed and enlightening that I am.

-- 
Jens Axboe

Re: Kernel includefile bug not fixed after a year :-(

[Andreas Steinmetz]

Jens Axboe wrote:
> 
> I think I do.
> 
> 
>>In order to use kernel interfaces you _need_ to include kernel include
>>files.
> 
> 
> False. You need to include the glibc kernel headers.
> 
Then please tell me why PPPIOCNEWUNIT is only defined in linux/if_ppp.h 
and not net/if_ppp.h which is still true for glibc-2.3.2. And please 
don't tell me to ask the glibc folks. There are inconsistencies between 
kernel headers and userland headers which force the inclusion of kernel 
headers in userland applications.

Re: Kernel includefile bug not fixed after a year :-(

[Jens Axboe]

On Tue, Sep 30 2003, Andreas Steinmetz wrote:
> Jens Axboe wrote:
> >
> >I think I do.
> >
> >
> >>In order to use kernel interfaces you _need_ to include kernel include
> >>files.
> >
> >
> >False. You need to include the glibc kernel headers.
> >
> Then please tell me why PPPIOCNEWUNIT is only defined in linux/if_ppp.h 
> and not net/if_ppp.h which is still true for glibc-2.3.2. And please 
> don't tell me to ask the glibc folks. There are inconsistencies between 
> kernel headers and userland headers which force the inclusion of kernel 
> headers in userland applications.

I will tell you to talk to the glibc folks, because that's where your
problem is.

-- 
Jens Axboe

Re: Kernel includefile bug not fixed after a year :-(

[Andreas Steinmetz]

Jens Axboe wrote:
> On Tue, Sep 30 2003, Andreas Steinmetz wrote:
> 
>>Jens Axboe wrote:
>>
>>>I think I do.
>>>
>>>
>>>
>>>>In order to use kernel interfaces you _need_ to include kernel include
>>>>files.
>>>
>>>
>>>False. You need to include the glibc kernel headers.
>>>
>>
>>Then please tell me why PPPIOCNEWUNIT is only defined in linux/if_ppp.h 
>>and not net/if_ppp.h which is still true for glibc-2.3.2. And please 
>>don't tell me to ask the glibc folks. There are inconsistencies between 
>>kernel headers and userland headers which force the inclusion of kernel 
>>headers in userland applications.
> 
> 
> I will tell you to talk to the glibc folks, because that's where your
> problem is.
> 
I don't think so. If ioctls are introduced in the kernel the kernel 
people should propagate these to the glibc people. I don't think it is 
the task of userland developers.
But then this is my point of view and I don't think it necessary to 
discuss this further.

-- 
Andreas Steinmetz
D.O.M. Datenverarbeitung GmbH

Re: Kernel includefile bug not fixed after a year :-(

[Jens Axboe]

On Tue, Sep 30 2003, Andreas Steinmetz wrote:
> Jens Axboe wrote:
> >On Tue, Sep 30 2003, Andreas Steinmetz wrote:
> >
> >>Jens Axboe wrote:
> >>
> >>>I think I do.
> >>>
> >>>
> >>>
> >>>>In order to use kernel interfaces you _need_ to include kernel include
> >>>>files.
> >>>
> >>>
> >>>False. You need to include the glibc kernel headers.
> >>>
> >>
> >>Then please tell me why PPPIOCNEWUNIT is only defined in linux/if_ppp.h 
> >>and not net/if_ppp.h which is still true for glibc-2.3.2. And please 
> >>don't tell me to ask the glibc folks. There are inconsistencies between 
> >>kernel headers and userland headers which force the inclusion of kernel 
> >>headers in userland applications.
> >
> >
> >I will tell you to talk to the glibc folks, because that's where your
> >problem is.
> >
> I don't think so. If ioctls are introduced in the kernel the kernel 
> people should propagate these to the glibc people. I don't think it is 
> the task of userland developers.

It's not solely their responsibility, I agree. Just see my mail to
davem. Did you tell the glibc folks about the missing ioctls?

> But then this is my point of view and I don't think it necessary to 
> discuss this further.

Agree. It's long been established that kernel headers aren't always
suitable for user space inclusion, this discussion doesn't change that
fact.

-- 
Jens Axboe

Re: Kernel includefile bug not fixed after a year :-(

[David S. Miller]

On Tue, 30 Sep 2003 14:21:37 +0200
Jens Axboe <axboe@suse.de> wrote:

> I will tell you to talk to the glibc folks, because that's where your
> problem is.

I think it's totally unreasonable to expect the glibc folks
to suck in every single new weird API that ends up in the kernel.

Part of this is our job.

But until we have that bit solved, it's irresonsible of us to tell
users to go scream at the glibc people.  Rather, we should fix the
(really, honestly, incredibly minor) things that prevent these kernel
header files from working for users.

Re: Kernel includefile bug not fixed after a year :-(

[Jens Axboe]

On Tue, Sep 30 2003, David S. Miller wrote:
> On Tue, 30 Sep 2003 14:21:37 +0200
> Jens Axboe <axboe@suse.de> wrote:
> 
> > I will tell you to talk to the glibc folks, because that's where your
> > problem is.
> 
> I think it's totally unreasonable to expect the glibc folks
> to suck in every single new weird API that ends up in the kernel.
> 
> Part of this is our job.

We agree 100% here, have you read any of my emails in this thread?! I'm
not trying to place blame, it's a joint effort for sure.

> But until we have that bit solved, it's irresonsible of us to tell
> users to go scream at the glibc people.  Rather, we should fix the
> (really, honestly, incredibly minor) things that prevent these kernel
> header files from working for users.

Talk to glibc folks: point out the inconsistency. Maybe he'll be a good
boy and provide a patch, who knows. That's doesn't imply screaming.

And yes, I'm not on a mission to make sure that kernel headers
absolutely don't work from user space. And I'm even sure that had Joerg
provided a patch in his original email, it might even have been included
in the kernel. The attitude surely doesn't help either.

-- 
Jens Axboe

Re: Kernel includefile bug not fixed after a year :-(

[David S. Miller]

On Tue, 30 Sep 2003 14:40:38 +0200
Jens Axboe <axboe@suse.de> wrote:

> We agree 100% here, have you read any of my emails in this thread?!

Great, we're on the same page, I didn't realize sorry.

> And I'm even sure that had Joerg provided a patch in his original
> email
 ...

Indeed, someone do this and let's everyone be happy.
But post it with a different subject line please :)

Re: Kernel includefile bug not fixed after a year :-(

[David S. Miller]

On Tue, 30 Sep 2003 14:12:06 +0200
Andreas Steinmetz <ast@domdv.de> wrote:

> Then please tell me why PPPIOCNEWUNIT is only defined in linux/if_ppp.h 
> and not net/if_ppp.h which is still true for glibc-2.3.2. And please 
> don't tell me to ask the glibc folks. There are inconsistencies between 
> kernel headers and userland headers which force the inclusion of kernel 
> headers in userland applications.

Indeed, and equally someone tell me where all the IPSEC socket
interface defines are in glibc?  It doesn't matter which tree
you check it won't be there.

Even if one is of the opinion that nobody should be including the
kernel headers, you must fully realize that as a matter of
practicality people absolutely must do this to use many kernel
interfaces to their full extent.

Suggest changes to fix the problems, but just saying "don't include
kernel header in your user apps, NYAH NYAH NYAH!" does not help
anyone at all.

Re: Kernel includefile bug not fixed after a year :-(

[Jens Axboe]

On Tue, Sep 30 2003, David S. Miller wrote:
> On Tue, 30 Sep 2003 14:12:06 +0200
> Andreas Steinmetz <ast@domdv.de> wrote:
> 
> > Then please tell me why PPPIOCNEWUNIT is only defined in linux/if_ppp.h 
> > and not net/if_ppp.h which is still true for glibc-2.3.2. And please 
> > don't tell me to ask the glibc folks. There are inconsistencies between 
> > kernel headers and userland headers which force the inclusion of kernel 
> > headers in userland applications.
> 
> Indeed, and equally someone tell me where all the IPSEC socket
> interface defines are in glibc?  It doesn't matter which tree
> you check it won't be there.

Did you notify them of the addition?

> Even if one is of the opinion that nobody should be including the
> kernel headers, you must fully realize that as a matter of
> practicality people absolutely must do this to use many kernel
> interfaces to their full extent.
> 
> Suggest changes to fix the problems, but just saying "don't include
> kernel header in your user apps, NYAH NYAH NYAH!" does not help
> anyone at all.

Well then change that to 'if you include kernel headers from your user
apps, be prepared to pick fix the breakage'.

Surely the kernel doesn't move at such an accelerated pace that it's
impossible to keep kernel headers uptodate.

-- 
Jens Axboe

Re: Kernel includefile bug not fixed after a year :-(

[David S. Miller]

On Tue, 30 Sep 2003 14:28:32 +0200
Jens Axboe <axboe@suse.de> wrote:

> On Tue, Sep 30 2003, David S. Miller wrote:
> > On Tue, 30 Sep 2003 14:12:06 +0200
> > Andreas Steinmetz <ast@domdv.de> wrote:
> > 
> > Indeed, and equally someone tell me where all the IPSEC socket
> > interface defines are in glibc?  It doesn't matter which tree
> > you check it won't be there.
> 
> Did you notify them of the addition?

Nope, and I don't expect them to be checking all the time.

This is as much kernel people's problem as glibc people's.
We, as kernel people, need a system that the glibc people can
get this crap automatically.  The glibc folks can then just use
it and everything just works.

> Well then change that to 'if you include kernel headers from your user
> apps, be prepared to pick fix the breakage'.

There is a very small amount of effort necessary to fix this
particular problem, it won't be the end of the world if we fix the
kernel header in the actual kernel sources for them.

Re: Kernel includefile bug not fixed after a year :-(

[Jens Axboe]

On Tue, Sep 30 2003, David S. Miller wrote:
> On Tue, 30 Sep 2003 14:28:32 +0200
> Jens Axboe <axboe@suse.de> wrote:
> 
> > On Tue, Sep 30 2003, David S. Miller wrote:
> > > On Tue, 30 Sep 2003 14:12:06 +0200
> > > Andreas Steinmetz <ast@domdv.de> wrote:
> > > 
> > > Indeed, and equally someone tell me where all the IPSEC socket
> > > interface defines are in glibc?  It doesn't matter which tree
> > > you check it won't be there.
> > 
> > Did you notify them of the addition?
> 
> Nope, and I don't expect them to be checking all the time.
> 
> This is as much kernel people's problem as glibc people's.
> We, as kernel people, need a system that the glibc people can
> get this crap automatically.  The glibc folks can then just use
> it and everything just works.

Yep, the 'notify them' implies active effort from the kernel developers.

> > Well then change that to 'if you include kernel headers from your user
> > apps, be prepared to pick fix the breakage'.
> 
> There is a very small amount of effort necessary to fix this
> particular problem, it won't be the end of the world if we fix the
> kernel header in the actual kernel sources for them.

I'm sure Joerg is quite capable of fixing the problem and making a
patch. That is the least he can do if he wants the problem to be fixed,
whining is well known to be a lot less effective than that.

-- 
Jens Axboe

Re: Kernel includefile bug not fixed after a year :-(

[Erik Andersen]

On Tue Sep 30, 2003 at 02:28:32PM +0200, Jens Axboe wrote:
> Well then change that to 'if you include kernel headers from your user
> apps, be prepared to pick fix the breakage'.
> 
> Surely the kernel doesn't move at such an accelerated pace that it's
> impossible to keep kernel headers uptodate.

A classic recent example is iproute, which uses kernel headers
all over the place.  It compiled with earlier 2.4.x kernels, but
it no longer compiles 2.4.22.  I've not bothered to try and fix
it, but if it included its own set of sanitized kernel headers,
it would not have had a problem.

 -Erik

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

Re: Kernel includefile bug not fixed after a year :-(

[Paul Rolland]

Hello,

> A classic recent example is iproute, which uses kernel headers
> all over the place.  It compiled with earlier 2.4.x kernels, but
> it no longer compiles 2.4.22.  I've not bothered to try and fix
> it, but if it included its own set of sanitized kernel headers,
> it would not have had a problem.

And if some IOCTLs were changed in between, in the kernel and
kernel headers ? 
You end up with an application that you can compile, but doesn't
behave as expected ? What a progress :-(

Regards,
Paul

 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BASIC programmers never die, they GOSUB and don't RETURN.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: Kernel includefile bug not fixed after a year :-(

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

On Wed, 2003-10-01 at 10:48, Paul Rolland wrote:
> Hello,
> 
> > A classic recent example is iproute, which uses kernel headers
> > all over the place.  It compiled with earlier 2.4.x kernels, but
> > it no longer compiles 2.4.22.  I've not bothered to try and fix
> > it, but if it included its own set of sanitized kernel headers,
> > it would not have had a problem.
> 
> And if some IOCTLs were changed in between, in the kernel and
> kernel headers ? 
this is absolutely not allowed to happen. It's not allowed to break the
userspace ABI like this!

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Kernel includefile bug not fixed after a year :-(

[Erik Andersen]

On Wed Oct 01, 2003 at 10:48:45AM +0200, Paul Rolland wrote:
> Hello,
> 
> > A classic recent example is iproute, which uses kernel headers
> > all over the place.  It compiled with earlier 2.4.x kernels, but
> > it no longer compiles 2.4.22.  I've not bothered to try and fix
> > it, but if it included its own set of sanitized kernel headers,
> > it would not have had a problem.
> 
> And if some IOCTLs were changed in between, in the kernel and
> kernel headers ? 
> You end up with an application that you can compile, but doesn't
> behave as expected ? What a progress :-(

People who change ioctl numbers needs their kneecaps broken.
Regardless, I didn't say I liked the current situation.  I
just said that is the current officially sanctioned method
of dealing with it,

 -Erik

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

Re: Kernel includefile bug not fixed after a year :-(

[Sam Ravnborg]

On Tue, Sep 30, 2003 at 05:23:37AM -0700, David S. Miller wrote:
> 
> Suggest changes to fix the problems, but just saying "don't include
> kernel header in your user apps, NYAH NYAH NYAH!" does not help
> anyone at all.

I really liked the proposal that Matthew Wilcox came up with:

Todays hirachi:
include/linux		=>	Kernel wide internal
include/sub-system	=>	sub-system internal
include/asm-$(ARCH)	=>	arch specific
include/asm		=>	symlink to include/asm-$(ARCH)
include/asm-generic	=>	default arch implementations

Additional hirachy:
usr/include/linux-abi	=>	kernel wide ABI
usr/include/abi-$(ARCH)	=>	arch specifics ABI
usr/include/arch-abi	=>	symlink to above

I've lost the original email, so the names differ, but the
principle is the same.

Then we could slowly migrate the user level stuff to usr/include.
Do you see this as a sensible solution also for ipv6?

	Sam

Re: Kernel includefile bug not fixed after a year :-(

[David S. Miller]

On Tue, 30 Sep 2003 18:10:18 +0200
Sam Ravnborg <sam@ravnborg.org> wrote:

> I really liked the proposal that Matthew Wilcox came up with:

Me too.

Re: Kernel includefile bug not fixed after a year :-(

[Eric W. Biederman]

Sam Ravnborg <sam@ravnborg.org> writes:

> On Tue, Sep 30, 2003 at 05:23:37AM -0700, David S. Miller wrote:
> > 
> > Suggest changes to fix the problems, but just saying "don't include
> > kernel header in your user apps, NYAH NYAH NYAH!" does not help
> > anyone at all.

One nasty part of the issue is that glibc has decided it is the master
of types and the glibc ABI is not compatible with the kernel ABI with
some fundamental types like dev_t.
 
> I really liked the proposal that Matthew Wilcox came up with:
> 
> Todays hirachi:
> include/linux		=>	Kernel wide internal
> include/sub-system	=>	sub-system internal
> include/asm-$(ARCH)	=>	arch specific
> include/asm		=>	symlink to include/asm-$(ARCH)
> include/asm-generic	=>	default arch implementations
> 
> Additional hirachy:
> usr/include/linux-abi	=>	kernel wide ABI
> usr/include/abi-$(ARCH)	=>	arch specifics ABI
> usr/include/arch-abi	=>	symlink to above

One case that does not handle cleanly because of the symlink
is cross compilation.  With a proliferation of 32/64bit architectures
I think that is something worth considering.

So I would make that:
include/linux-abi/              => kernel wide ABI
include/linux-abi/abi-$(ARCH)/  => arch specifics ABI
include/linux-abi/features.h    => Environment abstractor.

<linux-abi/features.h> would define a macro __LINUX_ARCH that used
like:  ``#include __LINUX_ARCH(syscalls.h)''

And the __LINUX_ARCH(X) would expand to the include directory
for the various architectures as appropriate.  

Something else that needs to happen is that all definitions that
are in flux should be surrounded with an #ifdef LINUX_EXPERIMENTAL or
something similar.  So people don't start using an ABI that is in
flux by mistake.

All type names need to have a __linux_ prefix so we do not pollute
the C namespace, and because our types and the types glibc
exports to user space are different.

All defines for ioctls and the like should be prefixed with __LINUX_
again because user space may be doing something different. 

For glibc and the like it should be easy enough to write a perl
script that identify what definitions are in the headers and creates
definitions for their saner cousins.  It is either that or we need
to define an interface definition language and have tools to process
that.

Fixed sized types need to be derived from stdint.h when compiling
in user space, so they work with any weird compiler around.

We should make this the plan of record for 2.7.  But this is nothing
to rush into because once it is decided what the architecture is going
to be or where a definition should live we really cannot move it,
except during the kernel development cycle when the definitions are
introduced.  

Eric

Re: Kernel includefile bug not fixed after a year :-(

[Erik Andersen]

On Tue Sep 30, 2003 at 05:23:37AM -0700, David S. Miller wrote:
> Suggest changes to fix the problems, but just saying "don't include
> kernel header in your user apps, NYAH NYAH NYAH!" does not help
> anyone at all.

Until someone gets off their butt and assembles a set of user
space kernel headers, the correct answer is "don't include kernel
headers, instead make private copies of the needed kernel defines
and structs and fixup the kernel types to use C99 types from
stdint.h"

I.e. do for yourself what the kernel folk have not done,

 -Erik

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

Re: Kernel includefile bug not fixed after a year :-(

[Nick Piggin]

Andreas Steinmetz wrote:

> Jens Axboe wrote:
>
>>
>> I think I do.
>>
>>
>>> In order to use kernel interfaces you _need_ to include kernel include
>>> files.
>>
>>
>>
>> False. You need to include the glibc kernel headers.
>>
> Then please tell me why PPPIOCNEWUNIT is only defined in 
> linux/if_ppp.h and not net/if_ppp.h which is still true for 
> glibc-2.3.2. And please don't tell me to ask the glibc folks. There 
> are inconsistencies between kernel headers and userland headers which 
> force the inclusion of kernel headers in userland applications.
>

A problem was raised and Jens answered it. The simple fact is that right
now linux kernel include files are often not suitable to include in user
space.

You are free to do what you like. You can just stick a ifndef / define
at the top of your program to fix it up nicely, or wait for glibc to
include it, or try to include you kernel headers. Please don't be
hostile toward people who are answering questions.

FWIW I think some people are looking at this for 2.7

Re: Kernel includefile bug not fixed after a year :-(

[Erik Andersen]

On Tue Sep 30, 2003 at 02:12:06PM +0200, Andreas Steinmetz wrote:
> Jens Axboe wrote:
> >
> >I think I do.
> >
> >
> >>In order to use kernel interfaces you _need_ to include kernel include
> >>files.
> >
> >
> >False. You need to include the glibc kernel headers.
> >
> Then please tell me why PPPIOCNEWUNIT is only defined in linux/if_ppp.h 
> and not net/if_ppp.h which is still true for glibc-2.3.2. And please 
> don't tell me to ask the glibc folks. There are inconsistencies between 
> kernel headers and userland headers which force the inclusion of kernel 
> headers in userland applications.

Wrong.  Userland applications should make private copies of all
needed kernel defines and structures, and then change any kernel
types to use standard C99 types from stdint.h.

 -Erik

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

Re: Kernel includefile bug not fixed after a year :-(

[Paul Rolland]

> Wrong.  Userland applications should make private copies of all
> needed kernel defines and structures, and then change any kernel
> types to use standard C99 types from stdint.h.

Disk are cheaper and cheaper !!!!

Please add to Makefile default behavior :

includes:
  cp -R /usr/src/linux/include/ .

all: includes ...

Paul

Kernel includefile bug not fixed after a year :-(

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]

A year after I did report this inconsistency, it is still not fixed

If include/scsi/scsi.h is included without __KERNEL__ #defined, then this
error message apears.

/usr/src/linux/include/scsi/scsi.h:172: parse error before "u8"
/usr/src/linux/include/scsi/scsi.h:172: warning: no semicolon at end of struct 
or union
/usr/src/linux/include/scsi/scsi.h:173: warning: data definition has no type or 
storage class

Is there no interest in user applications for kernel features or is there just
no kernel maintainer left over who makes the needed work?


Hints:

-	A type named "u8" is superfluous (even with __KERNEL__ #defined)
	because we have a standard type uint8_t

-	Kernel include files should be checked for use compliance with level 
	compilations on a regular base. It is the duty of the persons who
	make changes to make sure that their changes don't break things.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Re: Kernel includefile bug not fixed after a year :-(

[Jens Axboe]

On Tue, Sep 30 2003, Joerg Schilling wrote:
> A year after I did report this inconsistency, it is still not fixed
> 
> If include/scsi/scsi.h is included without __KERNEL__ #defined, then this
> error message apears.
> 
> /usr/src/linux/include/scsi/scsi.h:172: parse error before "u8"
> /usr/src/linux/include/scsi/scsi.h:172: warning: no semicolon at end of struct 
> or union
> /usr/src/linux/include/scsi/scsi.h:173: warning: data definition has no type or 
> storage class
> 
> Is there no interest in user applications for kernel features or is there just
> no kernel maintainer left over who makes the needed work?

/usr/include/scsi/scsi.h looks fine on my system, probably also on
yours. You should not include kernel headers in your user space program.

-- 
Jens Axboe