LKML Archive on
help / color / mirror / Atom feed
From: Michael Tokarev <>
Subject: /sys/$DEVPATH/uevent vs uevent attributes
Date: Fri, 12 Jan 2007 22:32:10 +0300	[thread overview]
Message-ID: <> (raw)

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 ;)



             reply	other threads:[~2007-01-12 19:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-12 19:32 Michael Tokarev [this message]
2007-01-13  0:48 ` Greg KH
2007-01-13  2:00   ` Michael Tokarev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \
    --subject='Re: /sys/$DEVPATH/uevent vs uevent attributes' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).