Theodore Y. Ts'o wrote:
> I don't intend to support Debian specific packaging hacks that only work
> for Debian
Ted, I resent your attitude, whatsmore, you are sadly out of date on this
issue, which was new two full years ago and is now very old news. The way
debian does this is the correct way according to Matthias Ulrich and it also
has Linus's blessing:
Appendix A
======== =
This document contains comments from Linus Torvalds (made in
an ``off-the-cuff'' personal email) to help clarify the rationale
behind the Debian way of handling symlinks, but this should not be
seen as an official policy statement by Linus. I'm attaching a
disclaimer in his own words.
The only reason that Linus's message is quoted in here is that
he can explain the technical reasons with far more lucidity than I
can, and now that I have permission to include his mail, I am
removing most of my far less facile efforts in that regard.
Need for isolating the C development Library from volatile
kernel headers
----------------------------------------------------------------------------
>> "David" == David Engel <[EMAIL PROTECTED]> said on Mon, 24 Feb 1997
>> "Linus" == Linus Torvalds said on Mon, 24 Feb 1997
David> Hi Linus,
David> No matter how well we try to explain ourselves, the symlinks issue
David> keeps coming up. Would you mind if we used your message below in
David> our responses?
Linus> Sure. Don't make it "the word of God" - please point out that
Linus> it was a off-the-bat personal reply to a question concerning
Linus> this, and while I'm more than happy to have the email
Linus> circulated it shouldn't be seen as a "official" document in any
Linus> way..
Linus> Linus
---------------------------------------------------------------------------
>> "Linus" == Linus Torvalds said on Wed, 22 Jan 1997:
Linus> The kernel headers used to make sense exporting to user space,
Linus> but the user space thing has grown so much that it's really not
Linus> practical any more. The problem with Debian is just that they
Linus> are different, not that they are doing anything wrong. That
Linus> leads to differences between the distributions, and that in
Linus> turn obviously can result in subtle problems.
Linus> As of glibc, the kernel headers will really be _kernel_
Linus> headers, and user level includes are user level
Linus> includes. Matthias Ulrich did that partly because I've asked
Linus> him to, but mainly just because it is no longer possible to try
Linus> to synchronize the libc and the kernel the way it used to
Linus> be. The symlinks have been a bad idea for at least a year now,
Linus> and the problem is just how to get rid of them
Linus> gracefully. Personally, I'm counting on glibc, which we are
Linus> already using on alpha.
Linus> Just to give you some idea of exactly why the includes really
Linus> can't be handled by simple symlinks: the main problem is
Linus> version skew. Lots of people want to upgrade their library
Linus> without affecting the kernel, and probably even more people
Linus> want to be able to upgrade their kernel without affecting their
Linus> compilation environment. Right now doing that has been
Linus> extremely fragile.
Linus> Just to give _one_ example of why the symlinks are bad: NR_OPEN
Linus> and "fd_set". I have had no end of problems making NR_OPEN
Linus> larger in the kernel, exactly _because_ of the damn
Linus> sym-links. If I just make NR_OPEN larger (the right thing to
Linus> do), the problem is that people with old libraries will now
Linus> compile against a header file that doesn't match the library
Linus> any more. And when the library internally uses another NR_OPEN
Linus> than the new program does, "interesting" things happen.
Linus> In contrast, with separate header files, this doesn't make any
Linus> difference. If I change NR_OPEN in the kernel, the compilation
Linus> environment won't notice UNTIL the library and associated
Linus> header files are changed: thus the user will continue to compile
Linus> with the old values, but because we'll still be binary
Linus> compatible, the worst thing that happens is that new programs
Linus> won't take advantage of new features unless the developer has
Linus> upgraded his library. Compare that to breaking subtly.
Linus> NR_OPEN is just _one_ example, and actually it's one of the
Linus> easier ones to handle (because the only thing that really makes
Linus> much of a difference when it comes to NR_OPEN is the fd_set
Linus> size - but it certainly bit some people). Another major problem
Linus> is name-space pollution: the POSIX/ANSI/XOpen rules are not
Linus> only complex, but they are actually contradictory too. And the
Linus> kernel header files really can't reasonably support all of the
Linus> intricacies very cleanly.
Linus> One specific example of why we want separate header files for
Linus> libraries and kernel is offered by glibc: Matthias wanted to
Linus> have a "sigset_t" that will suffice for the future when the
Linus> POSIX.1b realtime signals are implemented. But at the same time
Linus> he obviously wants to be able to support programming on
Linus> Linux-2.0 and the current 2.1 that do not have that support.
Linus> The _only_ reasonably clean way to handle these kinds of
Linus> problems is to have separate header files: user programs see a
Linus> larger sigset_t, and then the library interaction with the
Linus> kernel doesn't necessarily use all of the bits, for
Linus> example. Then later, when the kernel support is actually there,
Linus> it's just a matter of getting a new shared library, and voila,
Linus> all the realtime signals work.
Linus> The symlink approach simply wouldn't work for the above: that
Linus> would have required everybody who uses the library to have a
Linus> recent enough kernel that whatever magic all the above entails
Linus> would be available in the kernel header files. But not only
Linus> don't I want to pollute the kernel header files with user level
Linus> decisions, it's actually possible that somebody wants to run
Linus> glibc on a 1.2.x kernel, for example. We _definitely_ do not
Linus> want him to get a 32-bit sigset_t just because he is happy with
Linus> an old kernel.
Linus> Anyway, this email got longer than intended, but I just wanted
Linus> to make clear that the symlinks will eventually be going away
Linus> even in non-Debian distributions. Debian just happened to do it
Linus> first - probably because Debian seems to be more interested in
Linus> technical reasons than any old traditions. And technically, the
Linus> symlinks really aren't very good.
Linus> The _only_ reason for the symlinks is to immediately give
Linus> access to new features in the kernel when those happen. New
Linus> ioctl numbers etc etc. That was an overriding concern early on:
Linus> the kernel interfaces expanded so rapidly even in "normal"
Linus> areas that having the synchronization that symlinks offered was
Linus> a good thing.
Linus> However, the kernel interfaces aren't really supposed to change
Linus> all that quickly any more, and more importantly: the technical
Linus> users know how to fix things any way they want, so if they want
Linus> a new ioctl number to show up they can actually edit the header
Linus> files themselves, for example. But having separation is good
Linus> for the non-technical user, because there are less surprises
Linus> and package dependencies.
Linus> Anyway, something like the patch that David suggested will
Linus> certainly go in, although I suspect I'll wait for it to become
Linus> "standard" and the glibc first real release to take place.
, and I suspect that other hardware manufacturers that are
> enlightened enough to distribute drivers which are kernel modules in
> source form for their products will have a similar reaction --- the
> market is too small to justify spending a lot of engineering time to
> support a very distribution-specific build system.
>
> Date: Tue, 13 Jul 1999 09:16:09 +0200
> From: Andreas Jellinghaus <[EMAIL PROTECTED]>
>
> hmm. guess everyone has at least two different kernels (old working one and
> new compiled one). but there can be only one /usr/include/...
>
> The Rocketport drivers allow someone who can modify the Makefile to
> change /usr/src/linux to some other value to support more than one
> kernel.
>
> But I need to be able to support naive users that use whatever kernel
> that came with their distribution, and who aren't comfortable modifying
> Makefiles or compiling their own kernel. In the case of Comtrol
> Rocketports, these are typically scientists/researchers who purchased a
> Rocketport because they needed a large number of serial ports to control
> their data acquisition equipment. They are *not* interested in hacking
> kernels, and they don't want to modify Makefiles to change a -I flag.
>
>
> My worst-case nightmare is that the FHS starts encouraging distributions
> to make the same mistake Slackware did, which was to distribute
> completely mismatching kernel header files and kernels. Since building
> kernel modules require that header files match exactly (think
> /usr/include/linux/modversions.h), that means that I would have to tell
> naive, non-developer users that they first have to:
>
> 1) download kernel sources from ftp.kernel.org,
> 2) configure a kernel to match their hardware configuration,
> 3) build their own kernel
> 4) install their own kernel, and only then can they
> 5) build my device driver
>
> I hope people can understand why this would be a complete non-starter
> for a certain class of users, and why I might refuse to support my a
> kernel module on any distribution that made such a user-hostile design
> decision....
>
> - Ted
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
see shy jo
