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

* Re: /sys/$DEVPATH/uevent vs uevent attributes
  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
  0 siblings, 1 reply; 3+ messages in thread
From: Greg KH @ 2007-01-13  0:48 UTC (permalink / raw)
  To: Michael Tokarev; +Cc: linux-kernel

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

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

* Re: /sys/$DEVPATH/uevent vs uevent attributes
  2007-01-13  0:48 ` Greg KH
@ 2007-01-13  2:00   ` Michael Tokarev
  0 siblings, 0 replies; 3+ messages in thread
From: Michael Tokarev @ 2007-01-13  2:00 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-kernel

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

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