[LFS Trac] #2057: Udev-122

LFS Trac trac at linuxfromscratch.org
Mon May 19 20:19:47 PDT 2008


#2057: Udev-122
------------------------------------------+---------------------------------
 Reporter:  matthew at linuxfromscratch.org  |        Owner:  lfs-book at linuxfromscratch.org
     Type:  enhancement                   |       Status:  new                          
 Priority:  normal                        |    Milestone:  7.0                          
Component:  Book                          |      Version:  SVN                          
 Severity:  normal                        |   Resolution:                               
 Keywords:                                |  
------------------------------------------+---------------------------------
Comment (by Bryan Kadzban):

 Replying to [comment:26 LydianKnight]:
 > although I think the vast majority of users won't have more than one
 network adapter, wired+wireless at best

 And even if you have one wired/one wireless, you will usually have
 different basenames for the two interfaces (ethX versus wifiX/wlanX, athX,
 raX, etc.).  :-)

 > take a quick look at the /sys hierarchy, and after I've found something
 interesting, I run udevtest with the desired parameter to inspect some of
 the capabilities and information for a given adapter (same case as the
 naming for a CDRW drive, for example)

 Yeah; with some knowledge about all the different interfaces in the system
 (not just cards), and what makes each one unique, this works OK.  The
 issue is, if you don't know the pitfalls for your driver(s), it's easy to
 fall into them.  :-)

 > > Maybe none of that is needed in most cases.  But I've never liked the
 80/20 rule.  :-P
 >
 > Maybe my point of view sounded a bit selfish

 Not really -- that 80/20 comment was more because I hear a lot of it at
 work.  I don't really agree with a "The last 20% doesn't matter enough to
 worry about!" type of a mindset.

 It works out OK if you're looking at some physical system -- usually,
 anyway -- but software is usually a lot more complicated.  There is a
 limit beyond which you shouldn't worry (and maybe these multi-NIC cases
 are beyond that limit), but the limit is almost never at 80%; if only 80%
 of some system works, it's still too buggy, IMO.  :-)

 (Plus I always seem to be using the last 5%: the stuff that got left buggy
 because of some other group's equivalent of 80/20.  :-P )

 > we could add some text about the /sys hierarchy

 This is probably a good idea anyway.  At least an overview of what's where
 in current kernels, and how to find stuff starting in e.g. /sys/class or
 /sys/bus.

 > (but frankly speaking, would be nice to see this effort reaching a
 stable solution for all, no other distro seems to have reached a proper
 solution (at least debian like it's mentioned) and hey, that would
 definitely be a great point for LFS)

 You're right, but I think the reason other distros don't need this is that
 they don't really care what happens if you move from another distro to
 them.  You go via their CD (probably just like Debian), and their CD can
 generate the rules.  LFS is fairly unique that way, I think.

 > we're not asking users to patch/sed some lines of code in a given file
 to be able to accomodate their purposes, but to inspect a bit their new
 system to customize it a bit more

 Yeah, that's true, and maybe it's not terribly difficult.

 I guess my biggest issue with having users write the rules themselves is
 probably that I don't expect users to need to know whether their card
 requires a "special" rule or not, which means we'd have to tell them (or
 have them get it wrong).  We'd have to keep track of which type of setup
 would require extra match keys to work right, and if that gets missed
 (either we miss a new special setup, or if the user skips that section),
 then the whole system fails.

-- 
Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/2057#comment:27>
LFS Trac <http://wiki.linuxfromscratch.org/lfs/>
Linux From Scratch: Your Distro, Your Rules.



More information about the lfs-book mailing list