Kernel page, once again

Jeroen Coumans jeroen at linuxfromscratch.org
Tue Jun 15 00:22:27 PDT 2004


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.

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

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

> 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? ;-)
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. [...]

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

-- 
Groeten/Greetings,
Jeroen Coumans
{faq,website}@linuxfromscratch.org
www.jeroencoumans.nl



More information about the lfs-dev mailing list