udev problems

Jeroen Coumans jeroen at linuxfromscratch.org
Sat May 22 08:14:15 PDT 2004

Kevin P. Fleming said the following on 22-05-2004 16:28:
> Jeroen Coumans wrote:
>> "LFS has never been bleeding edge; it just used the latest stable 
>> release of a package if available. I don't see any reason to change 
>> that now, especially not to serve desktop use. That would be narrowing 
>> of our focus and target/intended audience. We're producing a book, not 
>> a distro."
> I can't speak to how udev may or may not fit into the LFS focus and/or 
> target, because I haven't been around here long enough. However, I can 
> say without any doubt that using "desktop use" as an example against the 
> inclusion of udev is not wise, as "desktop use" is where udev has its 
> most beneficial applications. Servers tend not to be based on hotplug 
> hardware, or certainly don't have hardware being added and removed 
> frequently (although udev still has benefits in that environment). 

I would like to remind you that we're *not* building a desktop here, we 
are also *not* building a distro. We are writing a book which can be 
used as the framework or basis for building your own distro. The 
inclusion of hotplug and udev is being justified because it *is* useful 
for desktops.

I get criticism because I specify a font type in the book's layout. The 
argument is: don't override the readers' choice, even if he didn't 
specify it. Fair enough; I hold a poll and will conform to its outcome. 
But now we're doing the opposite: by including udev (and hotplug) at 
this point, we're specifying something which *should* be a choice.

> Desktop systems, however, are more and more being used with plug-in 
> devices that the user would not otherwise know which device nodes are 
> for what device (witness a recent thread on the comp.sys.palmtops.pilot 
> newsgroup where a user could not figure out where his USB-connected Palm 
> device was appearing in /dev). I see the inclusion of udev as a 
> fantastic opportunity to teach LFS users how to manage which device 
> nodes correspond to their devices and to actually _learn_ how to take 
> advantage of that to make their system more useful for them.

The argument against inclusion of udev in LFS/testing is twofold:
1. it's not required yet
2. it's not ready yet (although opinions differ in that)

I continue to stress that it doesn't mean it should never be included, 
on the contrary! I have no objections to it being in unstable; after 
all, that is exactly the reason unstable exists! But the fact remains 
that it is not required yet, thus shouldn't be included according to 
current practices.

I'd also like to point out that there were several efforts to 
*standardise* our software selection procedure and come up with commonly 
agreed upon *principles*, eg. 
Despite that everybody applauded and supported the effort, it seems that 
it's just theory and the practice is that LFS will just include 
everything which its development team wish to include.

> If the core of these objections is that the included documentation with 
> udev has not been updated to reflect its "stable" nature, then I'm sure 
> I can get Greg K-H to post a message here to quell your concerns. I am 
> not going to bother doing that, though, if that is not the root cause of 
> the objections.

If he feels so confident in udev, then by all means push him to update 
his docs, because it is now misleading at best. But it still only takes 
care of (2) of the argument against inclusion of udev.

Jeroen Coumans

More information about the lfs-dev mailing list