#2057: Udev-122 ------------------------------------------+--------------------------------- Reporter: [EMAIL PROTECTED] | Owner: [email protected] 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 [EMAIL PROTECTED]: > 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. -- http://linuxfromscratch.org/mailman/listinfo/lfs-book FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
