Kernel page, once again
Alexander E. Patrakov
see at the.sig
Tue Jun 15 20:24:47 PDT 2004
Jeroen Coumans wrote:
> Summary of your long post (please correct me if I misrepresent you):
> 1. we should include configuration and documentation for all possible
> combinations of packages which a user can optionally install. This is
> because the current docs about hotplug/udev are insufficient, and there
> are too many problems a user can run into.
Correction: This is because the current docs about hotplug/udev are
insufficient, and there are too many problems a user can run into, and
troubleshooting these problems starts with getting hotplug and udev out
of the way.
> 2. if a package is optional and has alternatives, we should include at
> least one alternative.
> This goes IMHO exactly against the currently default principle that we
> should provide instructions and support for one default choice, but
> point out alternatives. Arguments:
> * including more then one alternative means you have to include all
> * there is no educational benefit for providing more then one package
> which serves the same function
> * we try to keep the number of packages in the book down because LFS
> does not try to be everything to all people
> * we have to assume the reader follows the book, because it would
> require not only a lot more support issues, but also testing and QA
> issues if we account for every deviation.
OK, I unconditionally agree with all your points except "there is no
educational benefit for providing more then one package which serves the
same function". The exception is because I don't completely understand
you. Do make_devices and udev serve the same function?
> Furthermore, in my POV, optional only means that the package is not
> required for a fully functional LFS system, not that the book provides
> instructions in case you leave it out. Perhaps we should declare all
> packages mandatory...
Sorry, I misunderstood you. Now everything is clear. We should provide
one default patch and working links to possible semi-supported deviations.
> Lastly, your points that udev's documentation is incomplete and it has a
> lot of possible traps are only arguments to reconsider the decision to
> include it in the book, not a reason to expand the book just because the
> package is not ready yet! I have repeatedly stated that I didn't
> consider udev ready for prime time (bleeding edge); seems that you just
> confirmed my opinion.
Udev is ready, its documentation is not. And I can write the missing
documentation. I have already submitted that to Greg KH, no response yet.
I will be satisfied with any of the following four solutions:
1) default to make_devices.sh + no hotplug, take udev and hotplug out of
2) Remove the bogus "modular-build" hint by Jim Gifford (or rename it to
modular-build-2.4 and replace 2.6 with 2.4 everywhere - then the hint
will be perfect), replace it with a real thing, put a link into the book.
3) Put udev and hotplug documentation into the book itself
4) Clearly state our current assumption that the reader knows everything
about hotplug, udev and modular kernels, and already has a working
combination of these three items. This would result in empty stated
target audience, but the fact is that our real target audience (i.e.,
set of people who are ready to read the book) is already empty.
I will prefer (2) or (3).
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