Kernel page, once again

Nathan Coulson conathan at conet.dyndns.org
Tue Jun 15 21:21:14 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
>> alternatives
>> * 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
> the book
> 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).

about number 2, Probably contacting the author of the hint would be a
better solution to getting your proposed changes, as well as a suggestion
on how udev has depreciated the modules.conf configuration.

A page on configuring udev and hotplug in chapter 7 could be handy I
beleve.  (BTW, on lfs-hackers, someone said there was a better way to
configure udev other then that config patch we apply [udev-26, I believe].
 Normally, I know that the book doesnt like to add package configuration
information to the book as such, [other then static configuration files
and/or an explination].  I was going to suggest adding how
/etc/rc.d/init.d/cleanfs can create additional files [such as kernel
modules] to a new page in chapter 7.  [for modules that do not export a
/sys interface, and not picked up by udev]

Out of curiosity, how much is explained in the building a kernel howto at
tldp?  I think we pointed to that [note, I never checked].



More information about the lfs-dev mailing list