Re: /sys/$DEVPATH/uevent vs uevent attributes
Greg KH wrote: > On Fri, Jan 12, 2007 at 10:32:10PM +0300, Michael Tokarev wrote: >> (No patch at this time, -- just asking about an.. idea ;) > > Let's see what such a patch looks like to see if it would be workable or > not. Umm.. it's definitely workable, and even almost trivial. Just splitting kobject_uevent() routine into two parts, one to format the environment variables, and one to actually send things over netlink and executing the hotplug_helper if defined, and using the first part to format the content of `uevent' file will do the trick. I don't know how to do the last part. > And no one forces you to use udev, I have machines with a static /dev > that work just fine :) It has less and less chances to work correctly. For example, this dynamic sdX thing, when I don't know anymore which sdX is which, without some help from /dev/disk/by-XXX/. And more and more software requires udev, at least as packages by distos. For example, today I've got rid of udev on one of our servers, which has been installed (debian) due to xen-utils having Depends: udev. Even when it doesn't *really* *require* udev, -- i replaced the whole thing with a 5-line shell script. /mjt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /sys/$DEVPATH/uevent vs uevent attributes
On Fri, Jan 12, 2007 at 10:32:10PM +0300, Michael Tokarev wrote: > > (No patch at this time, -- just asking about an.. idea ;) Let's see what such a patch looks like to see if it would be workable or not. And no one forces you to use udev, I have machines with a static /dev that work just fine :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
/sys/$DEVPATH/uevent vs uevent attributes
Not-so-recently already, device directories in /sys started providing files like modalias, which corresponds to $MODALIAS env. variable at uevent time. Also not-so-recently, uevent file appeared, which, when written, triggers re-execution of an uevent corresponding to the device. So far so good. But there's an inconsistency at least: why modalias file is here, while other attributes of an uevent aren't? If the proper way to refresh everything which has been detected during kernel boot (before userspace) is to use `uevent' triggers in sysfs, modalias files aren't needed - proper $MODALIAS will be here when an event will re-trigger. But if it's possible to refresh the things by just walking over /sys finding all device dirs, modalias file isn't sufficient. Current udev way of populating /dev at startup looks.. hackish at least. We start udevd, and start sending it uevents - all we find in /sys at that time. Kernel spews tons of events, and udevd has to serialize them somehow. Next, we're waiting for the storm to calm down, again using a hackish way - by waiting while current SEQNUM will be the same as last processed by udevd (which might never be a case by the way, due to, say, udevd crash or somesuch). What I was thinking is -- how about making uevent file readable too, to be able to sequentially walk over /sys, read environment from uevent files, and - again - sequentially execute things with that environment, without all the hackery currently implemented in udev, in a stright, clean and understandable way? Something like: . /etc/hotplug/config find /sys -name uevent | while read path; do ( read x < $path; eval $x; process_event; ) This way, it will also be possible to bring the ol'good udev-free days back (and did I mention I *detest* udev, and prefer simple, clean shell script instead, as far as I'm forced to use something to handle hotplug events?), without too much speed problems for example... (No patch at this time, -- just asking about an.. idea ;) Thanks. /mjt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
/sys/$DEVPATH/uevent vs uevent attributes
Not-so-recently already, device directories in /sys started providing files like modalias, which corresponds to $MODALIAS env. variable at uevent time. Also not-so-recently, uevent file appeared, which, when written, triggers re-execution of an uevent corresponding to the device. So far so good. But there's an inconsistency at least: why modalias file is here, while other attributes of an uevent aren't? If the proper way to refresh everything which has been detected during kernel boot (before userspace) is to use `uevent' triggers in sysfs, modalias files aren't needed - proper $MODALIAS will be here when an event will re-trigger. But if it's possible to refresh the things by just walking over /sys finding all device dirs, modalias file isn't sufficient. Current udev way of populating /dev at startup looks.. hackish at least. We start udevd, and start sending it uevents - all we find in /sys at that time. Kernel spews tons of events, and udevd has to serialize them somehow. Next, we're waiting for the storm to calm down, again using a hackish way - by waiting while current SEQNUM will be the same as last processed by udevd (which might never be a case by the way, due to, say, udevd crash or somesuch). What I was thinking is -- how about making uevent file readable too, to be able to sequentially walk over /sys, read environment from uevent files, and - again - sequentially execute things with that environment, without all the hackery currently implemented in udev, in a stright, clean and understandable way? Something like: . /etc/hotplug/config find /sys -name uevent | while read path; do ( read x $path; eval $x; process_event; ) This way, it will also be possible to bring the ol'good udev-free days back (and did I mention I *detest* udev, and prefer simple, clean shell script instead, as far as I'm forced to use something to handle hotplug events?), without too much speed problems for example... (No patch at this time, -- just asking about an.. idea ;) Thanks. /mjt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /sys/$DEVPATH/uevent vs uevent attributes
On Fri, Jan 12, 2007 at 10:32:10PM +0300, Michael Tokarev wrote: (No patch at this time, -- just asking about an.. idea ;) Let's see what such a patch looks like to see if it would be workable or not. And no one forces you to use udev, I have machines with a static /dev that work just fine :) thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /sys/$DEVPATH/uevent vs uevent attributes
Greg KH wrote: On Fri, Jan 12, 2007 at 10:32:10PM +0300, Michael Tokarev wrote: (No patch at this time, -- just asking about an.. idea ;) Let's see what such a patch looks like to see if it would be workable or not. Umm.. it's definitely workable, and even almost trivial. Just splitting kobject_uevent() routine into two parts, one to format the environment variables, and one to actually send things over netlink and executing the hotplug_helper if defined, and using the first part to format the content of `uevent' file will do the trick. I don't know how to do the last part. And no one forces you to use udev, I have machines with a static /dev that work just fine :) It has less and less chances to work correctly. For example, this dynamic sdX thing, when I don't know anymore which sdX is which, without some help from /dev/disk/by-XXX/. And more and more software requires udev, at least as packages by distos. For example, today I've got rid of udev on one of our servers, which has been installed (debian) due to xen-utils having Depends: udev. Even when it doesn't *really* *require* udev, -- i replaced the whole thing with a 5-line shell script. /mjt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
