Re: Debian conflicts with FHS on /usr/include/{linux,asm}
Raul Miller wrote (and the cc: list keeps geting longer ...):
>
> Theodore Y. Ts'o <tytso@mit.edu> wrote:
> > This path can be /usr/src/linux by default. Kernel modules should probably
> > not include /usr/include/{asm,linux} at all.
> >
> > I can live with this. But /usr/src/linux needs to be a valid default
> > that works for naive users.
>
> Ok, but let's take this back into the arena of FHS. I hope that FHS
> isn't only for naive users. [If FHS intends that distributions cannot
> support users with multiple kernels I'm going to be very disappointed.]
>
> According to the current FHS, as soon as you have a system which can
> boot two distinct kernels, the system is not FHS compliant. This is a
> bad thing, in my opinion.
>
> Alternatively, this is saying that all the historical boot mechanisms fail
> to be FHS compliant because they don't update /usr/include/{linux,asm}
> to match the booted kernel. Also not very good.
>
> I'd like to see FHS adopt some language where a system with more than
> one kernel instance can be FHS compliant.
Well, we have had several "big" changes, and some are still underway. Among
these are:
coff vs. elf
socks vs. traditional
ipv4 vs. ipv6
xhost vs. xauth
kerberos vs. non-kerberos
passwd vs. shadow
nis vs. dns (mostly on SunOS, though)
C vs. NLS-language
And some real stinkers coming up on the horizon:
32 bit vs. 64 bit (pointers, filesytems, ...)
ascii vs. unicode
In all cases many programs fell over on the new system, or had to be accommodated
(sometimes at great expense) by the newer paradigm (or by the user, in case of
Language. Maybe we should find a way in principle how to handle these fundamental
changes.
As for /usr/include/{linux,asm}, and in view of what Linus explained on sizes of
compiled structures, we should probably settle around:
/usr/include/linux (Linux-) kernel includes for the development environment
/usr/src/linux (link to) sources for the current kernel
That means that there should be a part of a startup script that does something like:
if test -L /usr/src/linux
then
rm -f /usr/src/linux
ln -s linux-`uname -r` /usr/src/linux
fi
if test -L /lib/modules/kotd
then
rm -f /lib/modules/kotd
ln -s `uname -r` /lib/modules/kotd
fi
It is clear that that is only possible where /usr/src is a link back to the machine
if /usr/src is mounted read-only.
Projects which use those include files should probably have a sanity check in the
makefile, to see if /usr/include/linux and /usr/src/linux/include are the same
directory (probably comparing the output of cd $i; /bin/pwd) and giving a warning
message in case they they don't like what they see.
N.B., should there be an alias for linux, in case people want to use kernel include
files without caring too much which kernel they are building with and for, or is
that just a stupid question - it probably would be better to migrate the include
file out of the kernel specific part in that case ...
Thomas
* Why not use metric units and get it right first time, every time ?
*
* email: cmaae47 @ imperial.ac.uk
Reply to: