[LFS Trac] #2057: Udev-122

LFS Trac trac at linuxfromscratch.org
Tue May 20 16:37:52 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:28 alexander at linuxfromscratch.org]:
 > and we should state this goal explicitly and provide a way to check this

 That sounds like a pretty good idea, actually.

 > (e.g., say that the *_rename interface will appear after the reboot in
 the case of an error).

 Hmm; I'm not sure that after the reboot is the best time to test it: it's
 already too late if you don't have (easy) physical access to the machine.
 But that's just an example, too.

 What may work is using udevtest, if we don't mind using it.  (Not sure on
 the status of it upstream: at one point I think it was slated to
 disappear, but that was before the ability to read from the sysfs uevent
 file was added to the kernel.)  If we run udevtest inside chroot for each
 NIC and make sure each one gets a different NAME applied, that may be
 sufficient.  Catching bugs that have to do with cards getting random MACs
 would be a problem, though.

 The rules won't be nearly as nice-looking as the ones that upstream
 generates, either.  Whether that matters or not is a different issue
 though.  :-)

 (Actually, one thing I haven't tried is seeing whether udevtest runs
 IMPORT{program} keys.  If it does, that may solve all the issues.  Let me
 test it...)

 HAH!  That should work fine.  :-)  OK, a new option:  Unless udevtest is
 evil for some other reason, we can just run:

 {{{
 for i in /sys/class/net/*[0-9] ; do
     udevtest $i
 done
 }}}

 , and that will pre-generate everything.  It will run the IMPORT programs
 just like udevd would.  Unless I'm missing something critical, this should
 work as long as udevtest keeps working that way.

 Replying to [comment:29 alexander at linuxfromscratch.org]:
 > So the only way to get out of this situation is to write location-based
 or driver-based rules manually.

 Well, that's one way to fix it.  Another way could be to let all the
 "local" MAC address cards get randomly-assigned names that grow from the
 top of the numeric range, and let all the "real" MAC address cards get
 persistent names at the bottom of the numeric range.

 For instance, say you have four cards, two of each type.  Give the first
 "real" card that gets rules generated for it eth0, and give the second
 "real" card eth1.  The other two cards will be given some name up higher;
 they could probably trade off between eth32767 and eth32766 (assuming the
 "top" of the range gets set to the maximum 16-bit signed integer).

 (Of course, path-based rules are probably easier.  They'd be even easier
 if path_id wouldn't require a "dev" attribute in sysfs for the DEVPATH in
 question; NICs don't have one.  :-) )

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



More information about the lfs-book mailing list