lkml.org 
[lkml]   [2007]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subject/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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-01-12 21:01    [W:0.024 / U:29.940 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site