Why 'linux/fs.h' cannot be included? I *can*...

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

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

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

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

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?

--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.

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.

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