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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni) If you don't have iso-8859-1
[email protected] (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
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
>From [email protected] 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni) If you don't have iso-8859-1
[email protected] (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
On Tue, Sep 30 2003, Joerg Schilling wrote:
> >From [email protected] 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
>From [email protected] 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni) If you don't have iso-8859-1
[email protected] (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
On Tue, Sep 30 2003, Joerg Schilling wrote:
>
> >From [email protected] 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
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.
On Tue, 30 Sep 2003 14:12:06 +0200
Andreas Steinmetz <[email protected]> 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.
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
On Tue, 30 Sep 2003 14:06:29 +0200
Jens Axboe <[email protected]> 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.
On Tue, Sep 30 2003, David S. Miller wrote:
> On Tue, 30 Sep 2003 14:12:06 +0200
> Andreas Steinmetz <[email protected]> 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
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
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
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
On Tue, 30 Sep 2003 14:21:37 +0200
Jens Axboe <[email protected]> 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.
On Tue, Sep 30 2003, David S. Miller wrote:
> On Tue, 30 Sep 2003 14:21:37 +0200
> Jens Axboe <[email protected]> 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
On Tue, Sep 30 2003, David S. Miller wrote:
> On Tue, 30 Sep 2003 14:06:29 +0200
> Jens Axboe <[email protected]> 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
On Tue, Sep 30 2003, David S. Miller wrote:
> On Tue, 30 Sep 2003 14:28:32 +0200
> Jens Axboe <[email protected]> wrote:
>
> > On Tue, Sep 30 2003, David S. Miller wrote:
> > > On Tue, 30 Sep 2003 14:12:06 +0200
> > > Andreas Steinmetz <[email protected]> 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
>From [email protected] 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni) If you don't have iso-8859-1
[email protected] (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
On Tue, 30 Sep 2003 14:28:32 +0200
Jens Axboe <[email protected]> wrote:
> On Tue, Sep 30 2003, David S. Miller wrote:
> > On Tue, 30 Sep 2003 14:12:06 +0200
> > Andreas Steinmetz <[email protected]> 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.
On Tue, 30 Sep 2003 14:40:38 +0200
Jens Axboe <[email protected]> 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 :)
>From [email protected] 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni) If you don't have iso-8859-1
[email protected] (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
>From [email protected] Tue Sep 30 14:28:23 2003
>On Tue, 30 Sep 2003 14:06:29 +0200
>Jens Axboe <[email protected]> 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:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni) If you don't have iso-8859-1
[email protected] (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
> [[email protected]]
>
> 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 <[email protected]>
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
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--
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--
Jens Axboe <[email protected]> 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
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--
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.