Kernel page, once again

Alexander E. Patrakov see at the.sig
Tue Jun 15 04:49:17 PDT 2004


Jeroen Coumans wrote:
> Alexander E. Patrakov said the following on 15-06-2004 06:31:
> 
>> Matthew Burgess wrote:
>>
>>> I've added my comments to those pages, and I don't think we should be
>>> looking at a considerably "larger timescale" for that type of stuff. 
>>> IMO it should be classed as a blocker for 6.0, but that is just my
>>> *opinion* not any kind of official line (yet).
>>
>>
>>
>> I second that. However, I propose slightly different changes from what
>> Matt proposed. It seems that we have to do the following:
>>
>> 1) Move all optional/replaceable packages to ch8. This currently
>> includes: e2fsprogs, reiserfsprogs (just for showing the reader that an
>> alternative exists), make_devices, udev, hotplug, module-init-tools, the
>> "modules" script, grub and lilo. Yes, I am strongly against the "one
>> true path" approach.
> 
> 
> I think it's better to stick to sane defaults and offer the user a 
> choice by pointing out alternatives. I don't see any reason to include 
> both e2fsprogs *and* resierfsprogs, etc. It simplifies instructions and 
> maintenance and we don't have to duplicate other documentation.
> Note that this has always been the case, and that it was changed because 
> people kept demanding for other alternatives to their packages. You 
> won't satisfy the boot crowd either; the Mac people will demand yaboot, 
> etc. Therefore, a long time ago, Gerard decided that LFS should remain a 
> book with singular choices, but with references to other docs (hints, 
> BLFS, etc.) if there is a choice.
> There is no "one true path", but it would be undoable to offer 
> instructions for all paths.

Below you, however, talk about optional packages. Could you please 
explain what's different between including alternative packages and 
including a package/no-package alternative?

Also, being afraid of demands from Chinese and mid-Asian people is the 
reason why there was no i18n in the book for a very long time.

>> 2) Write some introductory pages that can lead the reader to the right
>> choice. Mention that udev and hotplug are very hard to get right from
>> the first attempt with a modular kernel.
>>
>> I have talked with a professional teacher of phychology and she
>> convinced me that that defaulting to hotplug and udev is bad from
>> educational viewpoint since that violates a "one new complex thing at a
>> time" rule. Udev and hotplug are for those who come to LFS the second 
>> time.
> 
> 
> Why is udev/hotplug more complicated then our current build procedure? 
> It's just a matter of following instructions and reading properly, 
> right? And if properly setup, your hardware will be "automagically" 
> setup for you? (I have little/no experience with hotplug/udev; please 
> enlighten me).

The key words are "if properly setup". Proper setup includes: all 
executables in their place, correct configuration files, and correctly 
configured kernel (the correct modular kernel configuration with and 
without hotplug+udev is _very_ different). The book currently offers 
instructions that lead to all executable and configuration files (except 
modprobe.conf) installed correctly. However, the user expectations 
(including yours) are very often incorrect, and that's my fault: I 
should have given my "hardware detection" hint a less sounding name.

A user (e.g. Jeremy Utley!) usually thinks that hotplug will 
"automatically" probe all needed sound-related modules on his computer. 
The real result is that snd-emu10k1 is loaded, and snd-pcm-oss is not. 
However this is the _correct_ result! Hotplug is a very dumb generic 
script that just loads modules which say that they belong to your 
hardware. snd-pcm-oss is a generic wrapper around snd-pcm, and it 
doesn't belong to any particular hardware. Moreover, alsa-only 
configuration without snd-pcm-oss is perfectly valid! Therefore hotplug 
has no reason to load snd-pcm-oss.

One could say that there is no Debian-style "recommends" type of module 
dependencies, where snd-pcm could "recommend" snd-pcm-oss.

>> 3) Mention which modules will be loaded automatically and which devices
>> will be created on those pages.
> 
> 
> I thought the point of hotplug/udev was so that you don't have to 
> concern yourself with modules and devices anymore?

As you see above, this works only for certain kernel configurations that 
are documented nowhere except the attachment in the original message in 
this thread. Also, remember that Jeremy Utley (!) didn't get hotplug and 
udev right from the first attempt, and that had a reason (lack of 
documentation). Can we expect a typical reader to get them right?

So the point is invalid. Even with hotplug, there is a non-empty 
modprobe.conf file (that, however, unlike the traditional non-hotplug 
setup, works for all computers without changes: all lines are of the 
form "install usb-storage modprobe -i usb-storage ; modprobe sd-mod ; 
true"). Also there is a non-empty /etc/sysconfig/modules file 
(containing, e.g., ide-cd). My point is that it is documented _nowhere_ 
and we have to either delay the release indefinitely until such 
documentation appears, or to write such documentation ourselves and 
include it into the book. Some people think that it is a duplication of 
someone else's work, but Russians have a very good proverb on that: "? 
???? ????? ???? ??? ?????" ("Seven nurses have no eye on the baby").

>> If you don't agree with this bloat, please bump up the requirements on 
>> the "prerequisites" page: the builder must have already built a kernel 
>> that works well with udev and hotplug (that's much more than "already 
>> built a kernel"). We must either properly teach people to do that or 
>> clearly document that we expect people to already know that.
> 
> 
> How about removing udev and hotplug instead? ;-)

Unfortunately, this conflicts with the decision of other editors. 
However, I fully agree with you and I _will_ fork the book if I know 
that I am not the only one who will work at the forked book where 
alternatives and optional packages are permitted.

> I don't understand why the bloat is needed and why we can't explain it 
> as follows:
> 
> In this page we're going to install hotplug. This package is optional, 
> but it will take care of loading modules for your detected hardware 
> [etc...]. It requires the following kernel options: [...] Type the 
> following to install hotplug: [...]
> 
> In this page we're going to install udev. This package maintains your 
> /dev directory with the hardware which is detected by the kernel/hotplug 
> [etc...]. It is optional, but you'll need to install make_devices.sh 
> (see BLFS) or manually mknod all devices. [...]

This requires some precautions WRT modules. They are documented _only_ 
in the mail that started this thread, but people either refuse to 
include them (because my notes duplicate some nonexistent documentation) 
or are silent.

> In chapter 5, we recommend the user to install a distro 2.6 kernel or 
> built it themselves with instructions from other docs. We also recommend 
> to build it non-modulair. In chapter 8, we explain how we build a kernel 
> the LFS way.

Currently we don't. I don't count my stub that it is currently there and 
recommends building a non-modular kernel in ch8 because editors 
(including myself) are too lazy to include correct instructions for a 
modular one.

> We don't have to account for any deviation a reader may do, 
> but recommend one sound way of building it, while leaving the door open 
> to alternatives.

... while actually providing no support for them. This is not called an 
open door.

In fact, I recommend you to re-read the point (3) from my old post 
(other numbered points there are either irrelevant or invalid now):

http://archives.linuxfromscratch.org/mail-archives/lfs-hackers/2004-April/000731.html

-- 
Alexander E. Patrakov
To get my address: echo '0!42!+/6 at 5-3.535.25' | tr \!-: a-z | tr n .



More information about the lfs-dev mailing list