Hello all :))
I've reading the source code for 'blockdev', from util-linux, and
the comments says that the header 'linux/fs.h' cannot be included.
I've tried, just adding an include and removing the hand made
definitions (cloning those of fs.h), and all works ok :??
This header can be included or not? It works for me, with headers
from 2.4.17, so, is it just for backwards compatibility?
Thanks a lot in advance :)
Ra?l
DervishD <[email protected]> writes:
> Hello all :))
>
> I've reading the source code for 'blockdev', from util-linux, and
> the comments says that the header 'linux/fs.h' cannot be included.
> I've tried, just adding an include and removing the hand made
> definitions (cloning those of fs.h), and all works ok :??
>
> This header can be included or not? It works for me, with headers
> from 2.4.17, so, is it just for backwards compatibility?
Policy. It is for forwards compatibility. The general policy on kernel
headers is that if it breaks you get to keep the pieces.
Eric
Hello Eric :)
>> This header can be included or not? It works for me, with headers
>> from 2.4.17, so, is it just for backwards compatibility?
>Policy. It is for forwards compatibility. The general policy on kernel
>headers is that if it breaks you get to keep the pieces.
That is: I can include it if I just want the definition of a few
ioctl's, but if in a future version all that is changed or even
dissapears is completely my problem.
Given the number of user-space apps that needs ioctl definitions
and things like those (that are supposed not to change easily), those
definitions should go in user-includable headers... IMHO.
Fortunately, we have some of them in libc headers now.
Thanks,
Ra?l
On Tue, Jan 29, 2002 at 11:20:02AM +0100, DervishD wrote:
> Hello Eric :)
>
> >> This header can be included or not? It works for me, with headers
> >> from 2.4.17, so, is it just for backwards compatibility?
> >Policy. It is for forwards compatibility. The general policy on kernel
> >headers is that if it breaks you get to keep the pieces.
>
> That is: I can include it if I just want the definition of a few
> ioctl's, but if in a future version all that is changed or even
> dissapears is completely my problem.
>
> Given the number of user-space apps that needs ioctl definitions
> and things like those (that are supposed not to change easily), those
> definitions should go in user-includable headers... IMHO.
>
> Fortunately, we have some of them in libc headers now.
The policy is, never ever include kernel headers from userspace.
Your libc should provide a "sanitized" version of the kernel headers,
which is completely separate from any kernel sources.
dietlibc does this... it's completely independent of kernel header changes.
RedHat will be doing this with glibc in the future.
So, any problems should be reported to your libc maintainer :)
Jeff
> Your libc should provide a "sanitized" version of the kernel headers,
> which is completely separate from any kernel sources.
>
> dietlibc does this... it's completely independent of kernel header changes.
>
> RedHat will be doing this with glibc in the future.
We already do. Red Hat shipped since about 7.0 has a seperate set of
kernel based headers that glibc uses for its own internal use, and the set
in the kernel sources.
Alan
On Tue, Jan 29, 2002 at 02:51:43PM +0000, Alan Cox wrote:
> > Your libc should provide a "sanitized" version of the kernel headers,
> > which is completely separate from any kernel sources.
> >
> > dietlibc does this... it's completely independent of kernel header changes.
> >
> > RedHat will be doing this with glibc in the future.
>
> We already do. Red Hat shipped since about 7.0 has a seperate set of
> kernel based headers that glibc uses for its own internal use, and the set
> in the kernel sources.
To clarify, Arjan said the headers were going to be further sanitized,
and less just simple copies of selected kernel headers... <cheer>
That's what I wanted to say, but -ENOCAFFEINE :)
Jeff
Hi Jeff :)
>> Given the number of user-space apps that needs ioctl definitions
>> and things like those (that are supposed not to change easily), those
>> definitions should go in user-includable headers... IMHO.
>>
>> Fortunately, we have some of them in libc headers now.
>The policy is, never ever include kernel headers from userspace.
I know, but sometimes it is just impossible (when they aren't
appropriate glibc headers, for example). In fact, all this question
arose because I'm coding an 'ioctl' command line interface, so you
can send any 'documented' ioctl to any device. And, since I'm going
to start with block devices, I need linux/fs.h.
The problem is that I don't want to copy the definitions I need
from linux/fs.h, because this will lead to problems if those
definitions change. Anyway this is not an issue, because by changing
the running kernel those definitions in fact may not be valid...
Resuming: I don't know how properly address this problem.
>Your libc should provide a "sanitized" version of the kernel headers,
>which is completely separate from any kernel sources.
I suppose that those headers will contain definitions not subject
to change, won't they? But I don't know if I can consider the ioctl
constants as not subject to change (they should be permanent, though).
>So, any problems should be reported to your libc maintainer :)
Well, I try... I can even try to make the sanitized header myself
and pray for it to be included in next glibc revision :)
Thanks :)
Ra?l
DervishD <[email protected]> writes:
> Hi Jeff :)
>
> >> Given the number of user-space apps that needs ioctl definitions
> >> and things like those (that are supposed not to change easily), those
> >> definitions should go in user-includable headers... IMHO.
> >>
> >> Fortunately, we have some of them in libc headers now.
> >The policy is, never ever include kernel headers from userspace.
>
> I know, but sometimes it is just impossible (when they aren't
> appropriate glibc headers, for example). In fact, all this question
> arose because I'm coding an 'ioctl' command line interface, so you
> can send any 'documented' ioctl to any device. And, since I'm going
> to start with block devices, I need linux/fs.h.
>
> The problem is that I don't want to copy the definitions I need
> from linux/fs.h, because this will lead to problems if those
> definitions change. Anyway this is not an issue, because by changing
> the running kernel those definitions in fact may not be valid...
>
> Resuming: I don't know how properly address this problem.
In general you are running into the ioctls are messy problem, and probably
need to be cleaned up. Beyond that though ioctls should be static
they are part of the kernel ABI. Though they aren't managed tight
enough that you can count on them being 100% static.
> >Your libc should provide a "sanitized" version of the kernel headers,
> >which is completely separate from any kernel sources.
>
> I suppose that those headers will contain definitions not subject
> to change, won't they? But I don't know if I can consider the ioctl
> constants as not subject to change (they should be permanent,
> though).
In general ioctls are not be subject to change.
> >So, any problems should be reported to your libc maintainer :)
>
> Well, I try... I can even try to make the sanitized header myself
> and pray for it to be included in next glibc revision :)
Not that would be progress..
Eric
On Wed, Jan 30, 2002 at 01:07:37PM +0100, DervishD wrote:
> The problem is that I don't want to copy the definitions I need
> from linux/fs.h, because this will lead to problems if those
> definitions change. Anyway this is not an issue, because by changing
> the running kernel those definitions in fact may not be valid...
>
> Resuming: I don't know how properly address this problem.
Go ahead and copy. If ioctl interfaces change, then binary
compatibility just changed too. By nature that will be changed
infrequently, if at all.
Jeff
> The problem is that I don't want to copy the definitions I need
> from linux/fs.h, because this will lead to problems if those
> definitions change.
This is a common misconception. Traditional UNIX operates
this way, indeed. They do "make world" and build everything
in one go, so programs are automatically compatible with
the kernel (in theory, anyways). Once programs outside
of "make world" start to need access to these interfaces,
the scheme crumbles to the ground.
Linus (and thus Linux) consciously decided that this
so-called "souce compatibility" is a mirage. Only binary
compatibility matters. So, you must copy headers that
you wish to use, including linux/fs.h. Then, your program
is binary compatible with the kernel from which you took
them. New kernels may support your program by providing
the same interface, and they may have NO linux/fs.h
at all. If you included headers, you would not be
able to compile your program at all, but the old binary
would continue to work, and copied headers would continue
to work.
Those who come from UNIX background keep insisting to
include kernel headers, especially when they write
drivers with ioctl argument structures. But there is
no other way for them, but to educate themselves in
the Linux lore. Kernel headers are not to be included
in applications.
-- Pete
On Wed, 30 Jan 2002 13:24:22 -0500,
Pete Zaitcev <[email protected]> wrote:
>Kernel headers are not to be included in applications.
Just to flog this dead horse into the ground, the reverse is also true.
Kernel code must not include user space headers (kernel code excludes
programs that are used to build the kernel).
On Thu, Jan 31, 2002 at 10:33:46AM +1100, Keith Owens wrote:
> On Wed, 30 Jan 2002 13:24:22 -0500,
> Pete Zaitcev <[email protected]> wrote:
> >Kernel headers are not to be included in applications.
>
> Just to flog this dead horse into the ground, the reverse is also true.
> Kernel code must not include user space headers (kernel code excludes
> programs that are used to build the kernel).
Wow, does that actually occur? File references?
Jeff
On Wed, 30 Jan 2002 20:17:54 -0500,
Jeff Garzik <[email protected]> wrote:
>On Thu, Jan 31, 2002 at 10:33:46AM +1100, Keith Owens wrote:
>> On Wed, 30 Jan 2002 13:24:22 -0500,
>> Pete Zaitcev <[email protected]> wrote:
>> >Kernel headers are not to be included in applications.
>>
>> Just to flog this dead horse into the ground, the reverse is also true.
>> Kernel code must not include user space headers (kernel code excludes
>> programs that are used to build the kernel).
>
>Wow, does that actually occur? File references?
It slips in occasionally. LVM in 2.4.0-test had #include <endian.h>, I
vaguely remember some compression code that included glibc headers by
mistake. We weed them out of the kernel whenever we spot them, they
tend not to live very long. Christoph Hellwig suggested a Makefile
change that prevents kernel code including user space headers, it is
included in kbuild 2.5 and there is a 2.4 version in
http://marc.theaimsgroup.com/?l=linux-kernel&m=100321690511549&w=2
On Thu, Jan 31, 2002 at 12:51:50PM +1100, Keith Owens wrote:
> tend not to live very long. Christoph Hellwig suggested a Makefile
> change that prevents kernel code including user space headers, it is
> included in kbuild 2.5 and there is a 2.4 version in
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=100321690511549&w=2
Patch looks ok to me... The only thing I wonder is if we should put
kernel includes before gcc includes, just in case we want to override
something.
I would support putting this in the default cflags for 2.4 and 2.5...
Jeff
On Wed, 30 Jan 2002 20:57:14 -0500,
Jeff Garzik <[email protected]> wrote:
>On Thu, Jan 31, 2002 at 12:51:50PM +1100, Keith Owens wrote:
>> tend not to live very long. Christoph Hellwig suggested a Makefile
>> change that prevents kernel code including user space headers, it is
>> included in kbuild 2.5 and there is a 2.4 version in
>>
>> http://marc.theaimsgroup.com/?l=linux-kernel&m=100321690511549&w=2
>
>Patch looks ok to me... The only thing I wonder is if we should put
>kernel includes before gcc includes, just in case we want to override
>something.
I doubt that is ever a good idea. The kernel would have to track which
gcc was being used and work out what to override or duplicate. Why
make the kernel any more sensitive to gcc than we have to?
>I would support putting this in the default cflags for 2.4 and 2.5...
--nostdinc is the default for kbuild 2.5. I did not bother sending it
in for 2.4 because my kbuild 2.5 testing finds the naughty code anyway
and I send individual bug fixes for the offending files. There is also
a risk of breaking existing third party code, I was not willing to take
that risk on a "stable" series like 2.4.
On Thu, Jan 31, 2002 at 01:06:32PM +1100, Keith Owens wrote:
> On Wed, 30 Jan 2002 20:57:14 -0500,
> Jeff Garzik <[email protected]> wrote:
> >On Thu, Jan 31, 2002 at 12:51:50PM +1100, Keith Owens wrote:
> >> tend not to live very long. Christoph Hellwig suggested a Makefile
> >> change that prevents kernel code including user space headers, it is
> >> included in kbuild 2.5 and there is a 2.4 version in
> >>
> >> http://marc.theaimsgroup.com/?l=linux-kernel&m=100321690511549&w=2
> >
> >Patch looks ok to me... The only thing I wonder is if we should put
> >kernel includes before gcc includes, just in case we want to override
> >something.
>
> I doubt that is ever a good idea. The kernel would have to track which
> gcc was being used and work out what to override or duplicate. Why
> make the kernel any more sensitive to gcc than we have to?
The kernel often has special rules for and usage of gcc.
Why -prevent- the flexibility of doing this?
As soon as a case appears when we might need to care about what the gcc
headers are doing, we will want to do this anyway.
> >I would support putting this in the default cflags for 2.4 and 2.5...
>
> --nostdinc is the default for kbuild 2.5. I did not bother sending it
> in for 2.4 because my kbuild 2.5 testing finds the naughty code anyway
> and I send individual bug fixes for the offending files. There is also
> a risk of breaking existing third party code, I was not willing to take
> that risk on a "stable" series like 2.4.
Understandable... but I disagree :)
First, we rarely bend over backwards for 3rd party code, and more
importantly we should -never ever- do anything to assist and support
bad code.
Jeff