[LFS Trac] #2057: Udev-122

LFS Trac trac at linuxfromscratch.org
Sun May 18 16:15:15 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:                                |  
------------------------------------------+---------------------------------
Changes (by Bryan Kadzban):

  * summary:  Udev-120 => Udev-122

Comment:

 Replying to [comment:20 dnicholson at linuxfromscratch.org]:
 > I think that the right thing to do, if the --in-chroot patch is
 rejected,

 I've tried sending it to the -devel list; the only response at the time
 was from the maintainer of the Debian package (not sure on his status as
 an official udev maintainer), and wasn't very favorable.

 I didn't push it very hard upstream after that; I figured that if Debian
 had a way around it, we could probably figure something out too.  (Turns
 out their "way around it" is to use the same version of udev outside
 chroot, and then copy the rules during the install.  Not exactly going to
 work for us.)

 > would be to just right a stripped down udevd that just does what we
 want. Basically, just strip out all the parts of udevd.c that aren't
 applicable (like actual device creation and RUN rules), then add code for
 triggering the net events.

 Hmm.  So do the script, but do it in C so you have access to the data
 coming over the netlink socket for the uevent (including the subsystem,
 etc.), and don't have to guess about all of that info.

 There's more code from udev that would be needed than just udevd.c, I
 think: you'd need the rule parsing code, the sysfs access code (if that's
 still part of the package; I believe it is but haven't looked in a couple
 years), possibly the SELinux code (though not likely), etc.  If you kept
 it a daemon -- but there's no particular need to do that -- then you'd
 also need to keep the /dev/.udev/* handling code, so "udevadm settle"
 would work with it.

 Otherwise, you'd have to make it trigger the uevents itself, but that's
 just a readdir loop and writing to the uevent file.  Of course you'd have
 to somehow do that while it was listening for the uevents, which might be
 hard (otherwise it might miss them?  maybe not though; depends on the
 semantics of netlink sockets).

 The issue that I see would be keeping it in sync with the upstream code,
 so it can keep using the same set of rules.  I'm not sure whether that
 would be more work than keeping the patch in sync or not (really all the
 patch does is add code to recognize the command line option, and check the
 stored value in two or three places; it doesn't really change any upstream
 code, it just adds a few checks to skip some of it in certain cases).

 Hmm...

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



More information about the lfs-book mailing list