LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* /sys/$DEVPATH/uevent vs uevent attributes
@ 2007-01-12 19:32 Michael Tokarev
  2007-01-13  0:48 ` Greg KH
  0 siblings, 1 reply; 3+ messages in thread
From: Michael Tokarev @ 2007-01-12 19:32 UTC (permalink / raw)
  To: linux-kernel

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-01-13  2:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-01-12 19:32 /sys/$DEVPATH/uevent vs uevent attributes Michael Tokarev
2007-01-13  0:48 ` Greg KH
2007-01-13  2:00   ` Michael Tokarev

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