The Next Generation

The Next Generation

[Kay Sievers]

After the recent discussion about a possible new hotplug handler layout
I see the need for a completely different approach. We need to clean
up the current mess, reduce all the silly options and give a sane
environment without all the hacks and shortcomings.

A real "next generation" can only be sane with managed hotplug events,
which prevents races with sysfs timing and cares about order and
dependencies between the events.

The directory device match logic, even the more advanced one proposed
yesterday, will never meet our requirements to limit system usage
at event time. We should expect a ever growing number of hotplug events
and need to be prepared to execute only the stuff which is really needed
for a specific device.

For that reason, we should get rid of all the just too simple
brute-force logic in /etc/hotplug/*, /etc/hotplug.d/ and /etc/dev.d/, which
requires scripts to check if they are called for the right device.

I propose to make the udev architecture _the_ generic hotplug handler.
We use the same rules which we are using today to compose a name for a
specific device. We just need something like a POSTPROCESS="/sbin/some-program"
key for our rules which adds a program to a list of programs to be executed
after the device node is created.
udev needs a bit of tweaking to handle physical devices, but it applies the same
logic as we currently use for device naming.

This way we would get a nice, clean and understandable rule based event handling
with a single source of policy, and not the current mess with confusing directories
spreaded all over the system. And sure, it would give us the efficiency one can
expect from a "next generation" thing. :)

What do you think?

Thanks,
Kay


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

On Feb 17, Kay Sievers <kay.sievers@vrfy.org> wrote:

> What do you think?
I do not have an opinion about your proposed design yet, I'd like to
have a clear list of requirements first. An obvious requirement for
Debian is that I cannot make udev support mandatory (yet...), so it
would have to be possible to disable the devices-related features of
udev.

I agree that given the huge number of events generated by recent kernels
(if anybody disagrees, try creating a script to log them and load a few
modules) we need a solution smarter than "run a lot of programs and the
ones not interested in the event will exit", and possibly a long-running
daemon which received kernel events over a socket.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: The Next Generation

[Kay Sievers]

On Thu, 2005-02-17 at 21:21 +0100, Marco d'Itri wrote:
>On Feb 17, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> What do you think?
>I do not have an opinion about your proposed design yet, I'd like to
>have a clear list of requirements first. An obvious requirement for
>Debian is that I cannot make udev support mandatory (yet...), so it
>would have to be possible to disable the devices-related features of
>udev.

Yes, I thought about the same, we may just put an option in udev.conf.
You still get the nice udevd event management and this should also work
with /dev management disabled.

>I agree that given the huge number of events generated by recent kernels
>(if anybody disagrees, try creating a script to log them and load a few
>modules) we need a solution smarter than "run a lot of programs and the
>ones not interested in the event will exit", and possibly a long-running
>daemon which received kernel events over a socket.

Yes, a rule based helper execution with all the options a udev rule
already provides, will give us a very big speed gain, I think.

We are currently fixing the last subsystems that prevents us from
listening to the uevent netlink socket and possibly switch off the
forking of the helpers. We will get there this year, I hope.

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Alexander E. Patrakov]

Kay Sievers wrote:

> On Thu, 2005-02-17 at 21:21 +0100, Marco d'Itri wrote:
>>On Feb 17, Kay Sievers <kay.sievers@vrfy.org> wrote:
>>
>>> What do you think?
>>I do not have an opinion about your proposed design yet, I'd like to
>>have a clear list of requirements first. An obvious requirement for
>>Debian is that I cannot make udev support mandatory (yet...), so it
>>would have to be possible to disable the devices-related features of
>>udev.
> 
> Yes, I thought about the same, we may just put an option in udev.conf.
> You still get the nice udevd event management and this should also work
> with /dev management disabled.

Add to wishlist: I want to set permissions on files in /proc/bus/usb in some 
consistent manner, e.g. with udev rules.

-- 
Alexander E. Patrakov


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Roman Kagan]

On Thu, Feb 17, 2005 at 08:09:41PM +0100, Kay Sievers wrote:
> I propose to make the udev architecture _the_ generic hotplug handler.
> We use the same rules which we are using today to compose a name for a
> specific device. We just need something like a POSTPROCESS="/sbin/some-program"
> key for our rules which adds a program to a list of programs to be executed
> after the device node is created.
> udev needs a bit of tweaking to handle physical devices, but it applies the same
> logic as we currently use for device naming.

After initial indigestion, I get to like this approach.  Indeed,
allowing the hotplug multiplexer to apply sophisticated policies is a
good thing, and the current udev way of handling policies seems to cover
everything one may need.

I'd like to point out two issues in this regard:

1) NAME and SYMLINK rules become just a special case of rules, and
   should be treated as such.  This means that the namedev functionality
   should be logically isolated from the multiplexer functionality,
   probably not into a separate program, but at least it should be
   possible to compile out at build time and switch off at runtime.
   (This seems to have been mostly addressed in your patch)

2) the multiplexer shouldn't touch sysfs unless explicitly or implicitly
   requested to.  E.g. some of the keys in udev can be deduced from the
   environment variables passed to hotplug by the kernel.  (BTW a
   generic ENV{variable} key would be useful too.)  This would probably
   save quite a lot of open()/read()/close() calls, and would allow many
   rules not to wait_for_sysfs() at all.

   OTOH if a hotplug script wants to make sure a particular sysfs
   attribute is available when it runs, it would add
   SYSFS{attribute}="*" to its rule, so that the multiplexer does
   wait_for_sysfs() for it.

Cheers,
  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Kay Sievers]

On Thu, 2005-02-24 at 14:29 +0300, Roman Kagan wrote:
>On Thu, Feb 17, 2005 at 08:09:41PM +0100, Kay Sievers wrote:
>> I propose to make the udev architecture _the_ generic hotplug handler.
>> We use the same rules which we are using today to compose a name for a
>> specific device. We just need something like a POSTPROCESS="/sbin/some-program"
>> key for our rules which adds a program to a list of programs to be executed
>> after the device node is created.
>> udev needs a bit of tweaking to handle physical devices, but it applies the same
>> logic as we currently use for device naming.
>
>After initial indigestion, I get to like this approach.  Indeed,
>allowing the hotplug multiplexer to apply sophisticated policies is a
>good thing, and the current udev way of handling policies seems to cover
>everything one may need.
>
>I'd like to point out two issues in this regard:
>
>1) NAME and SYMLINK rules become just a special case of rules, and
>   should be treated as such.  This means that the namedev functionality
>   should be logically isolated from the multiplexer functionality,
>   probably not into a separate program, but at least it should be
>   possible to compile out at build time and switch off at runtime.
>   (This seems to have been mostly addressed in your patch)

Most of the new systems out there will never work without udev again,
but sure, we can have an option to skip node creation/removal. :)

As Marco already pointed out, it seems a bit confusing to stop the rule
processing if a NAME key is found, so no later HOTPLUG, SYMLINK key is
added to the list. We may change that, but let the first NAME key still
set the value? And we may introduce an additional OPTION to make a rule
final?

>2) the multiplexer shouldn't touch sysfs unless explicitly or implicitly
>   requested to.  E.g. some of the keys in udev can be deduced from the
>   environment variables passed to hotplug by the kernel.

The problem with the hotplug environment variables is backwards
compatibility. If we require a specific kernel version at some time, we
may do that - if it really helps.
And with the new libsysfs no attribute which is not explicitly
requested, will be openend.

>    (BTW a generic ENV{variable} key would be useful too.)

Yes, this will be nice, if we handle /sys/devices with rules.

>   OTOH if a hotplug script wants to make sure a particular sysfs
>   attribute is available when it runs, it would add
>   SYSFS{attribute}="*" to its rule, so that the multiplexer does
>   wait_for_sysfs() for it.

Nice idea. We may implement the whole wait_for_sysfs logic as a set of
rules. I like that.

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Roman Kagan]

On Thu, Feb 24, 2005 at 04:57:45PM +0000, Kay Sievers wrote:
> Most of the new systems out there will never work without udev again,

Right, but there may be reasons for people to stay with static /dev, and
it would be a pity not have the new cool hotplug there.

> As Marco already pointed out, it seems a bit confusing to stop the rule
> processing if a NAME key is found, so no later HOTPLUG, SYMLINK key is
> added to the list.

Is anything wrong with having multiple NAME?  Definitely not with device
nodes - you can have as many device nodes with the same major/minor
(e.g. pointing to the same physical device) as you wish, and that was
always so in Unix.  There may be certain problems with net devices, but
this sort of rules is typically created manually by sysadmin, not by
postinstall scripts of various packages, so conflicting rules here would
be his sole responsibility.

Just let me make my point clear: in a rule you have keys to match the
device against, and actions.  Currently known actions are NAME, SYMLINK,
and the proposed HOTPLUG.  On every hotplug event you go through the
list of rules in the order given in the configuration, and execute
actions in the rules whose keys match.  I don't see why NAME should be
treated differently from HOTPLUG (except it'd be handled internally by
udev).  Basically NAME=name is equivalent to HOTPLUG="udev_mknod name
SYSFS{dev}".

> >2) the multiplexer shouldn't touch sysfs unless explicitly or implicitly
> >   requested to.  E.g. some of the keys in udev can be deduced from the
> >   environment variables passed to hotplug by the kernel.
> 
> The problem with the hotplug environment variables is backwards
> compatibility. If we require a specific kernel version at some time, we
> may do that - if it really helps.

You're talking of the New Generation, aren't you :) ?  Still certain
keys can be deduced from the variables you already rely upon, like
DEVPATH, etc.

> And with the new libsysfs no attribute which is not explicitly
> requested, will be openend.

I think it can make sense to internally reorder the keys in the rule, to
make the keys which depend on sysfs be matched last (well, maybe still
before PROGRAM keys), so that the most lightweight checks happen first,
and the more heavyweight are skipped when the rule is already known not
to match.

> >    (BTW a generic ENV{variable} key would be useful too.)
> 
> Yes, this will be nice, if we handle /sys/devices with rules.

I can even imagine most existing keys to be transformed into either
ENV{} or SYSFS{}.  E.g. PLACE, ID, DRIVER can be obtained from $PHYS*.

Cheers,
  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Kay Sievers]

On Thu, 2005-02-24 at 20:51 +0300, Roman Kagan wrote:
>On Thu, Feb 24, 2005 at 04:57:45PM +0000, Kay Sievers wrote:

>> As Marco already pointed out, it seems a bit confusing to stop the rule
>> processing if a NAME key is found, so no later HOTPLUG, SYMLINK key is
>> added to the list.
>
>Is anything wrong with having multiple NAME?  Definitely not with device
>nodes - you can have as many device nodes with the same major/minor
>(e.g. pointing to the same physical device) as you wish, and that was
>always so in Unix.  There may be certain problems with net devices, but
>this sort of rules is typically created manually by sysadmin, not by
>postinstall scripts of various packages, so conflicting rules here would
>be his sole responsibility.
>
>Just let me make my point clear: in a rule you have keys to match the
>device against, and actions.  Currently known actions are NAME, SYMLINK,
>and the proposed HOTPLUG.  On every hotplug event you go through the
>list of rules in the order given in the configuration, and execute
>actions in the rules whose keys match.  I don't see why NAME should be
>treated differently from HOTPLUG (except it'd be handled internally by
>udev).  Basically NAME=name is equivalent to HOTPLUG="udev_mknod name
>SYSFS{dev}".

Hmm, I don't see the need for multiple device nodes now. We have
symlinks for that exact reason and it is much easier to manage the
permissions for a device if you have only one special file.

>> >2) the multiplexer shouldn't touch sysfs unless explicitly or implicitly
>> >   requested to.  E.g. some of the keys in udev can be deduced from the
>> >   environment variables passed to hotplug by the kernel.
>> 
>> The problem with the hotplug environment variables is backwards
>> compatibility. If we require a specific kernel version at some time, we
>> may do that - if it really helps.
>
>You're talking of the New Generation, aren't you :) ?  Still certain
>keys can be deduced from the variables you already rely upon, like
>DEVPATH, etc.

We already read DEVPATH from the env, we have no other option. :)

We need to run in the udvstart case where no env is available and
possibly walk up the chain of devices in /sys/devices to find a match. I
don't expect any significant improvement here.

>> And with the new libsysfs no attribute which is not explicitly
>> requested, will be openend.
>
>I think it can make sense to internally reorder the keys in the rule, to
>make the keys which depend on sysfs be matched last (well, maybe still
>before PROGRAM keys), so that the most lightweight checks happen first,
>and the more heavyweight are skipped when the rule is already known not
>to match.

The way the rule is parsed is independent of the order of match from the
first version of udev on.

>> >    (BTW a generic ENV{variable} key would be useful too.)
>> 
>> Yes, this will be nice, if we handle /sys/devices with rules.
>
>I can even imagine most existing keys to be transformed into either
>ENV{} or SYSFS{}.  E.g. PLACE, ID, DRIVER can be obtained from $PHYS*.

I like the explicit keys much more. And no, some of them have a special
way to match and need to work on any device along the chain of devices
in /sys/devices.
But sure, it is useful if would handle /sys/devices, cause we may need
to match against keys from the bus drivers.

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Roman Kagan]

On Thu, Feb 24, 2005 at 08:37:26PM +0100, Kay Sievers wrote:
> Hmm, I don't see the need for multiple device nodes now. We have
> symlinks for that exact reason and it is much easier to manage the
> permissions for a device if you have only one special file.

I didn't mean anybody needed multiple device nodes per se.  But AFAICS
the only reason the rule processing stops on the first NAME action is
the danger of enountering another NAME rule which would match; what I'm
trying to say is that there's no particular problem with multiple NAME
rules which can match the same device, and then all actions including
NAME, SYMLINK and HOTPLUG can be handled uniformly.

> We already read DEVPATH from the env, we have no other option. :)

Right, but $DEVPATH already contains some information about topology,
etc.  $PHYS* contain even more.  SUBSYSTEM is passed as an argument.
For many HOTPLUG and NAME actions the information obtained from the
environment would suffice.  But that would mean that they could be run
without waiting for the sysfs files to appear, and reading their
contents.

> We need to run in the udvstart case where no env is available and
> possibly walk up the chain of devices in /sys/devices to find a match. I
> don't expect any significant improvement here.

The hotplug multiplexer should be as lightweight as possible.  IMHO this
means that it should be constrained to the rule-based multiplexer and
optionally a component to execute NAME and SYMLINK actions.  What's in
udevstart now IMHO belongs in coldplug; the latter should reproduce
exactly the environment provided to the hotplug callout by the kernel.

> >I think it can make sense to internally reorder the keys in the rule, to
> >make the keys which depend on sysfs be matched last (well, maybe still
> >before PROGRAM keys), so that the most lightweight checks happen first,
> >and the more heavyweight are skipped when the rule is already known not
> >to match.
> 
> The way the rule is parsed is independent of the order of match from the
> first version of udev on.

Well, if people depend on the order keys in the rule are matched (I
don't see how, but still) then at least they can be recommended to put
the more lightweight checks first.  The match against an environment
variable costs nothing; the match against the contents of a sysfs file
costs a lot (waiting + file operations).

> >I can even imagine most existing keys to be transformed into either
> >ENV{} or SYSFS{}.  E.g. PLACE, ID, DRIVER can be obtained from $PHYS*.
> 
> I like the explicit keys much more.

I meant using environment internally, if possible.  E.g.

if (getenv("PHYSDEVPATH"))
	if (match PLACE against PHYSDEVPATH)
		goto matched;
if (match PLACE against sysfs)
	goto matched;
	
> And no, some of them have a special
> way to match and need to work on any device along the chain of devices
> in /sys/devices.

But some don't; I believe quite a few CPU cycles can be saved then.

Cheers,
  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Kevin P. Fleming]

Kay Sievers wrote:

> As Marco already pointed out, it seems a bit confusing to stop the rule
> processing if a NAME key is found, so no later HOTPLUG, SYMLINK key is
> added to the list. We may change that, but let the first NAME key still
> set the value? And we may introduce an additional OPTION to make a rule
> final?

Yes, please. It's never made sense to me to have a matching NAME rule 
cause udev to stop looking for other types of rules that may also apply. 
Now that you have added even more rule types, this will become a larger 
problem.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Greg KH]

On Thu, Feb 17, 2005 at 08:09:41PM +0100, Kay Sievers wrote:
> After the recent discussion about a possible new hotplug handler layout
> I see the need for a completely different approach. We need to clean
> up the current mess, reduce all the silly options and give a sane
> environment without all the hacks and shortcomings.

I agree.

> A real "next generation" can only be sane with managed hotplug events,
> which prevents races with sysfs timing and cares about order and
> dependencies between the events.

Ok.

> The directory device match logic, even the more advanced one proposed
> yesterday, will never meet our requirements to limit system usage
> at event time. We should expect a ever growing number of hotplug events
> and need to be prepared to execute only the stuff which is really needed
> for a specific device.

Ok.

> For that reason, we should get rid of all the just too simple
> brute-force logic in /etc/hotplug/*, /etc/hotplug.d/ and /etc/dev.d/, which
> requires scripts to check if they are called for the right device.

No, we can't break backward compatiblity like that.  We need to always
support the /etc/hotplug.d/ way, as we've already told too many people
they can rely on that always working.

We _can_ change the /etc/hotplug/ stuff, and I'm all for throwing the
mass of shell scripts there away.  I don't think there are very many
remaining external programs that still rely on putting themselves in
that directory.

And /etc/dev.d/ is also a good thing to have.

> I propose to make the udev architecture _the_ generic hotplug handler.

As much as I would _love_ to do this, we can't.  Too many people would
reject it.  We can't force udev onto everyone, no matter how many times
I tell them it's the right thing to do.

Now we _can_ build hotplug-ng out of udev pieces and parts, that I don't
have a problem with.  And, if udev is running on a box, have it handle
the hotplug functionality is also an acceptable thing (as long as
nothing external to udev has to change, like the scripts in
/etc/hotplug.d/).  But we can't mandate that udev must be used, sorry.

> We use the same rules which we are using today to compose a name for a
> specific device. We just need something like a POSTPROCESS="/sbin/some-program"
> key for our rules which adds a program to a list of programs to be executed
> after the device node is created.

Now I don't have a problem with this, but that's a udev specific thing,
not a hotplug handler thing.

> This way we would get a nice, clean and understandable rule based event handling
> with a single source of policy, and not the current mess with confusing directories
> spreaded all over the system. And sure, it would give us the efficiency one can
> expect from a "next generation" thing. :)

The main hotplug handling shouldn't be rule based, it should be driven
off of the subsystem and environment variables passed to it, like today.

What I want to see the hotplug-ng stuff handle is this:
	- not being a shell script, we need tiny and fast for both huge
	  boxes, and tiny embedded systems.
	- be a drop in replacement for the current /sbin/hotplug
	  multiplexer.
	- be a drop in replacement (through other helper programs) to
	  the existing linux-hotplug module loading scripts.
	- Extend the current hotplug functionality with a finer grained
	  way of executing other programs (like going off of the DEVPATH
	  or bus specific values, like was proposed on the
	  linux-hotplug-devel list.)
	- Possibly handle the wait-for-sysfs and reording logic that
	  udev currently does.

While not as far-reaching as your proposal, I think it is a good step
forward, as it addresses a number of issues that people have today with
the current hotplug setup, while not forcing anyone to convert to using
udev.

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

On Feb 26, Greg KH <greg@kroah.com> wrote:

> Now we _can_ build hotplug-ng out of udev pieces and parts, that I don't
> have a problem with.  And, if udev is running on a box, have it handle
> the hotplug functionality is also an acceptable thing (as long as
> nothing external to udev has to change, like the scripts in
> /etc/hotplug.d/).  But we can't mandate that udev must be used, sorry.
This was my first objection, but what's wrong with disabling the pieces
of udev which deal with devices creation and use the infrastructure for
hotplug?

> 	- be a drop in replacement (through other helper programs) to
> 	  the existing linux-hotplug module loading scripts.
.oO(no blacklisting support yet... :-) )

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: The Next Generation

[Greg KH]

On Sat, Feb 26, 2005 at 12:59:52AM +0100, Marco d'Itri wrote:
> On Feb 26, Greg KH <greg@kroah.com> wrote:
> 
> > Now we _can_ build hotplug-ng out of udev pieces and parts, that I don't
> > have a problem with.  And, if udev is running on a box, have it handle
> > the hotplug functionality is also an acceptable thing (as long as
> > nothing external to udev has to change, like the scripts in
> > /etc/hotplug.d/).  But we can't mandate that udev must be used, sorry.
> This was my first objection, but what's wrong with disabling the pieces
> of udev which deal with devices creation and use the infrastructure for
> hotplug?

There is nothing wrong with that, and I intend to do that (actually, if
you look at the current code, it is just that...)

> > 	- be a drop in replacement (through other helper programs) to
> > 	  the existing linux-hotplug module loading scripts.
> .oO(no blacklisting support yet... :-) )

Oh, I know :)

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Kay Sievers]

On Fri, 2005-02-25 at 15:17 -0800, Greg KH wrote:
>On Thu, Feb 17, 2005 at 08:09:41PM +0100, Kay Sievers wrote:
>> After the recent discussion about a possible new hotplug handler layout
>> I see the need for a completely different approach. We need to clean
>> up the current mess, reduce all the silly options and give a sane
>> environment without all the hacks and shortcomings.
>
>I agree.
>
>> A real "next generation" can only be sane with managed hotplug events,
>> which prevents races with sysfs timing and cares about order and
>> dependencies between the events.
>
>Ok.
>
>> The directory device match logic, even the more advanced one proposed
>> yesterday, will never meet our requirements to limit system usage
>> at event time. We should expect a ever growing number of hotplug events
>> and need to be prepared to execute only the stuff which is really needed
>> for a specific device.
>
>Ok.
>
>> For that reason, we should get rid of all the just too simple
>> brute-force logic in /etc/hotplug/*, /etc/hotplug.d/ and /etc/dev.d/, which
>> requires scripts to check if they are called for the right device.
>
>No, we can't break backward compatiblity like that.  We need to always
>support the /etc/hotplug.d/ way, as we've already told too many people
>they can rely on that always working.
>
>We _can_ change the /etc/hotplug/ stuff, and I'm all for throwing the
>mass of shell scripts there away.  I don't think there are very many
>remaining external programs that still rely on putting themselves in
>that directory.
>
>And /etc/dev.d/ is also a good thing to have.

No, I didn't like it from the first day on. :)
We should remove that crap and emulate dev.d/ with a external helper,
which is optional. A simple rule like:
  HOTPLUG="/sbin/dev_d-execute"

should do it.

>> I propose to make the udev architecture _the_ generic hotplug handler.
>
>As much as I would _love_ to do this, we can't.  Too many people would
>reject it.  We can't force udev onto everyone, no matter how many times
>I tell them it's the right thing to do.

SuSE and Fedora will never support any system without udev again. The
people who don't like udev can switch off the node creation or still
stick with todays hotplug. There will never be a sane Next Hotplug
without event management like udevd is doing. That will never work
reliable, like it was with the old multiplexer.

>Now we _can_ build hotplug-ng out of udev pieces and parts, that I don't
>have a problem with.  And, if udev is running on a box, have it handle
>the hotplug functionality is also an acceptable thing (as long as
>nothing external to udev has to change, like the scripts in
>/etc/hotplug.d/).  But we can't mandate that udev must be used, sorry.

They can stick with the old things, what's wrong with that? We can even
emulate the hotplug.d/ with your tiny multiplexer, by plugging it in
with a rule, the same way we can emulate dev.d/.

>> We use the same rules which we are using today to compose a name for a
>> specific device. We just need something like a POSTPROCESS="/sbin/some-program"
>> key for our rules which adds a program to a list of programs to be executed
>> after the device node is created.
>
>Now I don't have a problem with this, but that's a udev specific thing,
>not a hotplug handler thing.

But we already handle hotplug.d/ with udev today. There is not much of a
difference. :)

>> This way we would get a nice, clean and understandable rule based event handling
>> with a single source of policy, and not the current mess with confusing directories
>> spreaded all over the system. And sure, it would give us the efficiency one can
>> expect from a "next generation" thing. :)
>
>The main hotplug handling shouldn't be rule based, it should be driven
>off of the subsystem and environment variables passed to it, like today.
>
>What I want to see the hotplug-ng stuff handle is this:
>	- not being a shell script, we need tiny and fast for both huge
>	  boxes, and tiny embedded systems.
>	- be a drop in replacement for the current /sbin/hotplug
>	  multiplexer.
>	- be a drop in replacement (through other helper programs) to
>	  the existing linux-hotplug module loading scripts.
>	- Extend the current hotplug functionality with a finer grained
>	  way of executing other programs (like going off of the DEVPATH
>	  or bus specific values, like was proposed on the
>	  linux-hotplug-devel list.)
>	- Possibly handle the wait-for-sysfs and reording logic that
>	  udev currently does.

All that is already there in udev/udevd. You just need to be able to
switch the node creation/removal off.

>While not as far-reaching as your proposal, I think it is a good step
>forward, as it addresses a number of issues that people have today with
>the current hotplug setup, while not forcing anyone to convert to using
>udev.

And again, I really don't know what we can do _with_ udev for people who
don't want it. There will never be a Next Generation without sequence
reordering and sysfs waiting.

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[David Brownell]

On Thursday 17 February 2005 11:09 am, Kay Sievers wrote:
> After the recent discussion about a possible new hotplug handler layout
> I see the need for a completely different approach. We need to clean
> up the current mess, reduce all the silly options and give a sane
> environment without all the hacks and shortcomings.

That is, a third generation of how to manage the userspace events:

 - /etc/hotplug scripts, 2.4.0-test10 and later.  These introduced
   the newish notion that Linux should should primarily respond to
   configuration events on-the-fly, delegating hardware-to-driver
   policy to the kernel modules and other setup policies to various
   userspace tools.  This was essential before USB or CardBus/PCI
   could become widely used.

 - /etc/hotplug.d, phasing in during 2.6 along with enhancements to
   use the driver model more effectively (and udev).  More bus types;
   and sysfs meant the hotplug events didn't need to carry as much
   data (though their handlers might need to wait longer).

 - Next Generation (TBD)

Somehow I don't think this can stop with one "next generation"!  The
Linux developer community is still evolving how it wants to see
different systems reconfigure.  Today's "Next Generation" will be
tomorrow's silly limitation/hack ... to be replaced or evolved.


> A real "next generation" can only be sane with managed hotplug events,
> which prevents races with sysfs timing and cares about order and
> dependencies between the events.

The current generation is managed too ... you just want to see it
managed _differently_ ... :)

Though it's also worth (IMO) distinguishing various different aspects
of management.  I usually draw the lines as:  what the events are
(contents etc); how the kernel delivers them (e.g. does it deliver
in-order, through uevents or /sbin/hotplug, etc); and how they get
dispatched through userland.  That latter can involve multiple
frameworks, begging questions about how they interoperate.


> For that reason, we should get rid of all the just too simple
> brute-force logic in /etc/hotplug/*, /etc/hotplug.d/ and /etc/dev.d/, which
> requires scripts to check if they are called for the right device.

That'd be /etc/hotplug/$BUS/$MODULE if I understand what you mean,
but yes I certainly support being able to decommission /etc/hotplug.
Not as a "change everything, flag day!" event though.

The original logic for expecting those scripts to check that stuff
was that there was no better option.  The driver model started to
give us such options, especially once it let the hotplug events
see (albeit indirectly through sysfs) the /dev node associated with
a given physical device ... and decouple the "modprobe driver"
event from the "driver activates /dev node" event.

Remember that it amazed enough people at the time just to see
Linux systems automatically load the driver module ... it took
most developers a while to realize some of the missing steps!


> I propose to make the udev architecture _the_ generic hotplug handler.

Speaking as someone who's been content to let other folk drive the
evolution of hotplug for a while, I think it's not yet ready; but
I'm not averse to moving away from shell scripts as the main glue.
For the first generation, shell scripts were essential.

Why do I say it's not yet ready?  One example:  I recently configured
an OpenEmbedded build to use udev (instead of devfs) and that grew
the boot time from about 5 seconds to about 3 minutes.  (With a very
generic kernel, and not many devices ...) Considering that the target
is closer to one second, "udev" clearly lost big.  And I've seen
corresponding udev thrashing from my SuSE 9.2 laptop; cutting battery
lifetime by 15% when I plug in a CF card (AND am lucky enough to notice
and find a way to kill the endless loop) is not good.  


> This way we would get a nice, clean and understandable rule based event handling
> with a single source of policy, and not the current mess with confusing directories
> spreaded all over the system.

Like it or not, dynamically configuring a complex system must
involve multiple sources of (sometimes conflicting) policy,
and modular design that probably means multiple directories.

And _evolving_ a working system means that probably a few
messy vestiges will be left around ... 


> And sure, it would give us the efficiency one can 
> expect from a "next generation" thing. :)

Sounds like apple pie -- tasty!  Or "democracy", wherein the
devil is in the details (like who decides who gets to vote, and
for who/what, and whether their wishes are then ignored).

- Dave



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Kay Sievers]

On Sun, 2005-02-27 at 12:13 -0800, David Brownell wrote:
>On Thursday 17 February 2005 11:09 am, Kay Sievers wrote:
>> After the recent discussion about a possible new hotplug handler layout
>> I see the need for a completely different approach. We need to clean
>> up the current mess, reduce all the silly options and give a sane
>> environment without all the hacks and shortcomings.
>
>That is, a third generation of how to manage the userspace events:
>
> - /etc/hotplug scripts, 2.4.0-test10 and later.  These introduced
>   the newish notion that Linux should should primarily respond to
>   configuration events on-the-fly, delegating hardware-to-driver
>   policy to the kernel modules and other setup policies to various
>   userspace tools.  This was essential before USB or CardBus/PCI
>   could become widely used.
>
> - /etc/hotplug.d, phasing in during 2.6 along with enhancements to
>   use the driver model more effectively (and udev).  More bus types;
>   and sysfs meant the hotplug events didn't need to carry as much
>   data (though their handlers might need to wait longer).
>
> - Next Generation (TBD)
>
>Somehow I don't think this can stop with one "next generation"!  The
>Linux developer community is still evolving how it wants to see
>different systems reconfigure.  Today's "Next Generation" will be
>tomorrow's silly limitation/hack ... to be replaced or evolved.

Sure, it was the -ng in Greg's new hotplug package that lead to that
subject. :)

>> A real "next generation" can only be sane with managed hotplug events,
>> which prevents races with sysfs timing and cares about order and
>> dependencies between the events.
>
>The current generation is managed too ... you just want to see it
>managed _differently_ ... :)
>
>Though it's also worth (IMO) distinguishing various different aspects
>of management.  I usually draw the lines as:  what the events are
>(contents etc); how the kernel delivers them (e.g. does it deliver
>in-order, through uevents or /sbin/hotplug, etc); and how they get
>dispatched through userland.  That latter can involve multiple
>frameworks, begging questions about how they interoperate.

That does mean what?

>> For that reason, we should get rid of all the just too simple
>> brute-force logic in /etc/hotplug/*, /etc/hotplug.d/ and /etc/dev.d/, which
>> requires scripts to check if they are called for the right device.
>
>That'd be /etc/hotplug/$BUS/$MODULE if I understand what you mean,
>but yes I certainly support being able to decommission /etc/hotplug.
>Not as a "change everything, flag day!" event though.

Oh, we do not want break anything here. Every current stuff will be
plugged in by default as long as it is needed. And we need rules to
handle that and not directories. There are too many options/values to
match at event time to get a sane directory layout, I think.

>The original logic for expecting those scripts to check that stuff
>was that there was no better option.  The driver model started to
>give us such options, especially once it let the hotplug events
>see (albeit indirectly through sysfs) the /dev node associated with
>a given physical device ... and decouple the "modprobe driver"
>event from the "driver activates /dev node" event.
>
>Remember that it amazed enough people at the time just to see
>Linux systems automatically load the driver module ... it took
>most developers a while to realize some of the missing steps!

Yeah, that's a good point. People on the bleeding edge tend to forget
all that.

>> I propose to make the udev architecture _the_ generic hotplug handler.
>
>Speaking as someone who's been content to let other folk drive the
>evolution of hotplug for a while, I think it's not yet ready; but
>I'm not averse to moving away from shell scripts as the main glue.
>For the first generation, shell scripts were essential.
>
>Why do I say it's not yet ready?  One example:  I recently configured
>an OpenEmbedded build to use udev (instead of devfs) and that grew
>the boot time from about 5 seconds to about 3 minutes.  (With a very
>generic kernel, and not many devices ...) Considering that the target
>is closer to one second, "udev" clearly lost big.  And I've seen
>corresponding udev thrashing from my SuSE 9.2 laptop; cutting battery
>lifetime by 15% when I plug in a CF card (AND am lucky enough to notice
>and find a way to kill the endless loop) is not good.  

It is a pcmcia device, right? The kernel does not work well here and it
is not udev's fault. We talked to the kernel guys, cause with HAL we had
the same trouble but got not very friendly responses and gave up on
that. :(

But we did a lot of things over the last weeks to address the other
problems. We have a new libsysfs now, which is much much faster, we have
the "bus" link and don't need to look at all the files in sysfs to get
the bus value the device is on and we have the driver and physical
device in the environment and don't need to wait for something that will
never show up in sysfs.
We will get rules for the dev.d/ scripts which cuts the running time of
udevstart to ~30% on my box.
And I sent a patch to change to the kobject core to be able to send the
hotplug events after the default files in sysfs are created which will
be much nicer than todays stat() looping udev processes.

Let me know of any concrete problems with the newer kernel+udev versions
you see on any of your boxes and I will see what I can do.

It may even be an option for the embedded stuff to run a very tiny udev
without a dependency on sysfs, cause all the basic informations (bus,
driver, physical device, major/minor) are available with the hotplug
environment now.

>> This way we would get a nice, clean and understandable rule based event handling
>> with a single source of policy, and not the current mess with confusing directories
>> spreaded all over the system.
>
>Like it or not, dynamically configuring a complex system must
>involve multiple sources of (sometimes conflicting) policy,
>and modular design that probably means multiple directories.

Hmm, we just talk about handling hotplug events. What do you have in
mind here? If you see any specific problem, let me know.

>And _evolving_ a working system means that probably a few
>messy vestiges will be left around ... 

Sure, that's the way how every complex system is, right?

>> And sure, it would give us the efficiency one can 
>> expect from a "next generation" thing. :)
>
>Sounds like apple pie -- tasty!  Or "democracy", wherein the
>devil is in the details (like who decides who gets to vote, and
>for who/what, and whether their wishes are then ignored).

Yes, but we still need to move to see what we need to change. :)

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Roman Kagan]

A bit OT...

On Mon, Feb 28, 2005 at 12:34:57AM +0100, Kay Sievers wrote:
> And I sent a patch to change to the kobject core to be able to send the
> hotplug events after the default files in sysfs are created which will
> be much nicer than todays stat() looping udev processes.

Can you please give a pointer to this patch?  I'd like to take a look,
but I seem to be unable to find it...

Thanks,
  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Kay Sievers]

On Mon, 2005-02-28 at 20:02 +0300, Roman Kagan wrote:
>A bit OT...
>
>On Mon, Feb 28, 2005 at 12:34:57AM +0100, Kay Sievers wrote:
>> And I sent a patch to change to the kobject core to be able to send the
>> hotplug events after the default files in sysfs are created which will
>> be much nicer than todays stat() looping udev processes.
>
>Can you please give a pointer to this patch?  I'd like to take a look,
>but I seem to be unable to find it...

  http://marc.theaimsgroup.com/?l=linux-kernel&m\x110939796218870&w=2

Best,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Kay Sievers]

On Fri, Feb 25, 2005 at 03:17:14PM -0800, Greg KH wrote:
> On Thu, Feb 17, 2005 at 08:09:41PM +0100, Kay Sievers wrote:
> > For that reason, we should get rid of all the just too simple
> > brute-force logic in /etc/hotplug/*, /etc/hotplug.d/ and /etc/dev.d/, which
> > requires scripts to check if they are called for the right device.
> 
> No, we can't break backward compatiblity like that.  We need to always
> support the /etc/hotplug.d/ way, as we've already told too many people
> they can rely on that always working.

...

> And /etc/dev.d/ is also a good thing to have.

Ok, ok, here is a more intelligent replacement. :)

I've changes the HOTPLUG key to be able to read a whole subdirectory
with a wildcard instead of only one file. The following three rules will
emulate the dev.d/ directory handling we currently have compiled in:

  HOTPLUG="/etc/dev.d/%D/*.dev"
  HOTPLUG="/etc/dev.d/%S/*.dev"
  HOTPLUG="/etc/dev.d/default/*.dev"

The nice thing with this approach is that a program called specified twice
will only added once to the list of programs to be executed.

We can ship these rules by default which remains the needed backwards
compatibility, but the user can remove these rules and udev does not need
to search for anything outside the specified rules.

How does that sound now?

Thanks,
Kay

=== namedev.c 1.189 vs edited ==--- 1.189/namedev.c	2005-02-24 12:13:24 +01:00
+++ edited/namedev.c	2005-02-28 17:54:21 +01:00
@@ -168,8 +168,7 @@ static int find_free_number(struct udevi
 }
 
 static void apply_format(struct udevice *udev, char *string, size_t maxsize,
-			 struct sysfs_class_device *class_dev,
-			 struct sysfs_device *sysfs_device)
+			 struct sysfs_class_device *class_dev, struct sysfs_device *sysfs_device)
 {
 	char temp[NAME_SIZE];
 	char temp2[NAME_SIZE];
@@ -203,26 +202,18 @@ static void apply_format(struct udevice 
 
 		switch (c) {
 		case 'p':
-			if (strlen(udev->devpath) = 0)
-				break;
 			strfieldcatmax(string, udev->devpath, maxsize);
 			dbg("substitute kernel name '%s'", udev->kernel_name);
 			break;
 		case 'b':
-			if (strlen(udev->bus_id) = 0)
-				break;
 			strfieldcatmax(string, udev->bus_id, maxsize);
 			dbg("substitute bus_id '%s'", udev->bus_id);
 			break;
 		case 'k':
-			if (strlen(udev->kernel_name) = 0)
-				break;
 			strfieldcatmax(string, udev->kernel_name, maxsize);
 			dbg("substitute kernel name '%s'", udev->kernel_name);
 			break;
 		case 'n':
-			if (strlen(udev->kernel_number) = 0)
-				break;
 			strfieldcatmax(string, udev->kernel_number, maxsize);
 			dbg("substitute kernel number '%s'", udev->kernel_number);
 				break;
@@ -235,7 +226,7 @@ static void apply_format(struct udevice 
 			dbg("substitute major number '%u'", major(udev->devt));
 			break;
 		case 'c':
-			if (strlen(udev->program_result) = 0)
+			if (udev->program_result[0] = '\0')
 				break;
 			/* get part part of the result string */
 			i = 0;
@@ -326,6 +317,14 @@ static void apply_format(struct udevice 
 			strfieldcatmax(string, udev->tmp_node, maxsize);
 			dbg("substitute temporary device node name '%s'", udev->tmp_node);
 			break;
+		case 'S':
+			strfieldcatmax(string, udev->subsystem, maxsize);
+			dbg("substitute subsystem '%s'", udev->subsystem);
+			break;
+		case 'D':
+			strfieldcatmax(string, udev->name, maxsize);
+			dbg("substitute node name '%s'", udev->name);
+			break;
 		case 'r':
 			strfieldcatmax(string, udev_root, maxsize);
 			dbg("substitute udev_root '%s'", udev_root);
@@ -571,7 +570,7 @@ static int match_rule(struct udevice *ud
 	if (dev->kernel[0] != '\0') {
 		dbg("check for " FIELD_KERNEL " dev->kernel='%s' class_dev->name='%s'",
 		    dev->kernel, class_dev->name);
-		if (strcmp_pattern(dev->kernel, class_dev->name) != 0) {
+		if (strcmp_pattern(dev->kernel, udev->kernel_name) != 0) {
 			dbg(FIELD_KERNEL " is not matching");
 			goto exit;
 		}
@@ -588,6 +587,16 @@ static int match_rule(struct udevice *ud
 		dbg(FIELD_SUBSYSTEM " matches");
 	}
 
+	if (dev->action[0] != '\0') {
+		dbg("check for " FIELD_ACTION " dev->action='%s' class_dev->name='%s'",
+		    dev->action, class_dev->name);
+		if (strcmp_pattern(dev->action, udev->action) != 0) {
+			dbg(FIELD_ACTION " is not matching");
+			goto exit;
+		}
+		dbg(FIELD_ACTION " matches");
+	}
+
 	/* walk up the chain of physical devices and find a match */
 	while (1) {
 		/* check for matching driver */
@@ -689,13 +698,13 @@ exit:
 	return -1;
 }
 
-int namedev_name_device(struct udevice *udev, struct sysfs_class_device *class_dev)
+int rules_get_name(struct udevice *udev, struct sysfs_class_device *class_dev)
 {
 	struct sysfs_class_device *class_dev_parent;
 	struct sysfs_device *sysfs_device = NULL;
 	struct config_device *dev;
 
-	dbg("class_dev->name='%s'", class_dev->name);
+	dbg("udev->devpath='%s'", udev->devpath);
 
 	/* Figure out where the "device"-symlink is at.  For char devices this will
 	 * always be in the class_dev->path.  On block devices, only the main block
@@ -722,6 +731,10 @@ int namedev_name_device(struct udevice *
 	list_for_each_entry(dev, &config_device_list, node) {
 		dbg("process rule");
 		if (match_rule(udev, dev, class_dev, sysfs_device) = 0) {
+			if (dev->name[0] != '\0' && udev->name[0] != '\0') {
+				dbg("node name already set, rule ignored");
+				continue;
+			}
 
 			/* apply options */
 			if (dev->ignore_device) {
@@ -730,7 +743,7 @@ int namedev_name_device(struct udevice *
 				return -1;
 			}
 			if (dev->ignore_remove) {
-				udev->ignore_remove = dev->ignore_remove;
+				udev->ignore_remove = 1;
 				dbg_parse("remove event should be ignored");
 			}
 			/* apply all_partitions option only at a main block device */
@@ -738,6 +751,10 @@ int namedev_name_device(struct udevice *
 				udev->partitions = dev->partitions;
 				dbg("creation of partition nodes requested");
 			}
+			if (dev->no_hotplug) {
+				udev->no_hotplug = 1;
+				dbg_parse("supress hotplug program execution");
+			}
 
 			/* apply permissions */
 			if (dev->mode != 0000) {
@@ -768,7 +785,14 @@ int namedev_name_device(struct udevice *
 				strfieldcat(udev->symlink, temp);
 			}
 
-			/* rule matches */
+			/* collect hotplug programs */
+			if (dev->hotplug[0] != '\0') {
+				dbg("configured rule in '%s[%i]' added hotplug program '%s'",
+				     dev->config_file, dev->config_line, dev->hotplug);
+				name_list_add(&udev->hotplug_list, dev->hotplug, 0);
+			}
+
+			/* set the name of the node */
 			if (dev->name[0] != '\0') {
 				info("configured rule in '%s[%i]' applied, '%s' becomes '%s'",
 				     dev->config_file, dev->config_line, udev->kernel_name, dev->name);
@@ -781,21 +805,136 @@ int namedev_name_device(struct udevice *
 				if (udev->type != NET)
 					dbg("name, '%s' is going to have owner='%s', group='%s', mode=%#o partitions=%i",
 					    udev->name, udev->owner, udev->group, udev->mode, udev->partitions);
+			}
 
-				goto exit;
+			if (dev->last_rule) {
+				dbg("last rule key found, processing will stop at this rule");
+				break;
 			}
 		}
 	}
 
 	/* no rule matched, so we use the kernel name */
-	strfieldcpy(udev->name, udev->kernel_name);
-	dbg("no rule found, use kernel name '%s'", udev->name);
+	if (udev->name[0] = '\0') {
+		strfieldcpy(udev->name, udev->kernel_name);
+		dbg("no rule found, use kernel name '%s'", udev->name);
+	}
 
-exit:
 	if (udev->tmp_node[0] != '\0') {
 		dbg("removing temporary device node");
 		unlink_secure(udev->tmp_node);
 		udev->tmp_node[0] = '\0';
+	}
+
+	return 0;
+}
+
+int rules_get_hotplug(struct udevice *udev)
+{
+	struct config_device *dev;
+
+	/* look for a matching rule to apply */
+	list_for_each_entry(dev, &config_device_list, node) {
+		dbg("process rule");
+
+		if (dev->hotplug[0] = '\0')
+			continue;
+
+		/* skip rules that can't match */
+		if (dev->bus[0] != '\0' || dev->id[0] != '\0' ||
+		    dev->place[0] != '\0' || dev->sysfs_pair[0].file[0] != '\0' ||
+		    dev->program[0] != '\0' || dev->result[0] != '\0' ||
+		    dev->driver[0] != '\0')
+			continue;
+
+		if (dev->action[0] != '\0') {
+			dbg("check for " FIELD_ACTION " dev->action='%s' udev->action='%s'",
+			    dev->action, udev->action);
+			if (strcmp(dev->action, udev->action) != 0) {
+				dbg(FIELD_ACTION " is not matching");
+				continue;
+			}
+			dbg(FIELD_ACTION " matches");
+		}
+
+		if (dev->subsystem[0] != '\0') {
+			dbg("check for " FIELD_SUBSYSTEM " dev->subsystem='%s' udev->subsystem='%s'",
+			    dev->subsystem, udev->subsystem);
+			if (strcmp_pattern(dev->subsystem, udev->subsystem) != 0) {
+				dbg(FIELD_SUBSYSTEM " is not matching");
+				continue;
+			}
+			dbg(FIELD_SUBSYSTEM " matches");
+		}
+
+		if (dev->kernel[0] != '\0') {
+			dbg("check for " FIELD_KERNEL " dev->kernel='%s' class_dev->name='%s'",
+			    dev->kernel, udev->kernel_name);
+			if (strcmp_pattern(dev->kernel, udev->kernel_name) != 0) {
+				dbg(FIELD_KERNEL " is not matching");
+				continue;
+			}
+			dbg(FIELD_KERNEL " matches");
+		}
+
+		/* rule matches, see if hotplug programs should run*/
+		if (dev->no_hotplug) {
+			udev->no_hotplug = 1;
+			dbg_parse("supress hotplug program execution");
+			return -1;
+		}
+
+		name_list_add(&udev->hotplug_list, dev->hotplug, 0);
+	}
+
+	return 0;
+}
+
+static int hotplug_list_insert(struct udevice *udev, const char *name)
+{
+	char temp[NAME_SIZE];
+
+	strfieldcpy(temp, name);
+	apply_format(udev, temp, NAME_SIZE, NULL, NULL);
+	dbg("applied format '%s'",  temp);
+	name_list_add(&udev->hotplug_list, temp, 0);
+
+	return 0;
+}
+
+int rules_expand_hotplug_list(struct udevice *udev)
+{
+	struct name_entry *name_loop;
+	struct name_entry *name_tmp;
+
+	list_for_each_entry_safe(name_loop, name_tmp, &udev->hotplug_list, node) {
+		apply_format(udev, name_loop->name, NAME_SIZE, NULL, NULL);
+		dbg("applied format '%s'",  name_loop->name);
+
+		/* allow wildcard to add all files with a specific suffix */
+		if (strchr(name_loop->name, '*')) {
+			char directory[NAME_SIZE];
+			char *pos;
+
+			strfieldcpy(directory, name_loop->name);
+			pos = strrchr(directory, '/');
+			if (pos = NULL)
+				return -1;
+			pos[0] = '\0';
+			pos++;
+
+			if (strchr(pos, '*') = NULL)
+				continue;
+
+			pos = strrchr(pos, '.');
+			if (pos = NULL)
+				continue;
+
+			dbg("remove '%s' as command, instead search for '%s'-suffix in '%s'",
+			    name_loop->name, pos, directory);
+			list_del(&name_loop->node);
+			call_foreach_file(hotplug_list_insert, udev, directory, pos);
+		}
 	}
 
 	return 0;
=== namedev.h 1.40 vs edited ==--- 1.40/namedev.h	2005-02-21 06:48:12 +01:00
+++ edited/namedev.h	2005-02-28 17:32:04 +01:00
@@ -34,10 +34,10 @@ struct sysfs_class_device;
 #define ID_SIZE			64
 #define PLACE_SIZE		64
 #define DRIVER_SIZE		64
-#define PROGRAM_SIZE		128
 
 #define FIELD_KERNEL		"KERNEL"
 #define FIELD_SUBSYSTEM		"SUBSYSTEM"
+#define FIELD_ACTION		"ACTION"
 #define FIELD_BUS		"BUS"
 #define FIELD_SYSFS		"SYSFS"
 #define FIELD_ID		"ID"
@@ -51,10 +51,13 @@ struct sysfs_class_device;
 #define FIELD_GROUP		"GROUP"
 #define FIELD_MODE		"MODE"
 #define FIELD_OPTIONS		"OPTIONS"
+#define FIELD_HOTPLUG		"HOTPLUG"
 
-#define ATTR_IGNORE_DEVICE	"ignore_device"
-#define ATTR_IGNORE_REMOVE	"ignore_remove"
-#define ATTR_PARTITIONS		"all_partitions"
+#define OPTION_LAST_RULE	"last_rule"
+#define OPTION_IGNORE_DEVICE	"ignore_device"
+#define OPTION_IGNORE_REMOVE	"ignore_remove"
+#define OPTION_NO_HOTPLUG	"no_hotplug"
+#define OPTION_ALL_PARTITIONS	"all_partitions"
 
 #define MAX_SYSFS_PAIRS		5
 
@@ -70,6 +73,7 @@ struct config_device {
 
 	char kernel[NAME_SIZE];
 	char subsystem[SUBSYSTEM_SIZE];
+	char action[ACTION_SIZE];
 	char bus[BUS_SIZE];
 	char id[ID_SIZE];
 	char place[PLACE_SIZE];
@@ -87,6 +91,10 @@ struct config_device {
 	int partitions;
 	int ignore_device;
 	int ignore_remove;
+	int no_hotplug;
+	int last_rule;
+
+	char hotplug[PROGRAM_SIZE];
 
 	char config_file[NAME_SIZE];
 	int config_line;
@@ -94,9 +102,12 @@ struct config_device {
 
 extern struct list_head config_device_list;
 
-extern int namedev_init(void);
-extern int namedev_name_device(struct udevice *udev, struct sysfs_class_device *class_dev);
-extern void namedev_close(void);
+extern int rules_init(void);
+extern void rules_close(void);
+
+extern int rules_get_name(struct udevice *udev, struct sysfs_class_device *class_dev);
+extern int rules_get_hotplug(struct udevice *udev);
+extern int rules_expand_hotplug_list(struct udevice *udev);
 
 extern void dump_config_dev(struct config_device *dev);
 extern void dump_config_dev_list(void);
=== namedev_parse.c 1.52 vs edited ==--- 1.52/namedev_parse.c	2005-02-25 18:52:03 +01:00
+++ edited/namedev_parse.c	2005-02-28 12:39:46 +01:00
@@ -98,7 +98,7 @@ static char *get_key_attribute(char *str
 	return NULL;
 }
 
-static int namedev_parse(const char *filename, void *data)
+static int rules_parse(struct udevice *udev, const char *filename)
 {
 	char line[LINE_SIZE];
 	char *bufline;
@@ -183,6 +183,12 @@ static int namedev_parse(const char *fil
 				continue;
 			}
 
+			if (strcasecmp(temp2, FIELD_ACTION) = 0) {
+				strfieldcpy(dev.action, temp3);
+				valid = 1;
+				continue;
+			}
+
 			if (strcasecmp(temp2, FIELD_BUS) = 0) {
 				strfieldcpy(dev.bus, temp3);
 				valid = 1;
@@ -250,11 +256,11 @@ static int namedev_parse(const char *fil
 				attr = get_key_attribute(temp2 + sizeof(FIELD_NAME)-1);
 				/* FIXME: remove old style options and make OPTIONS= mandatory */
 				if (attr != NULL) {
-					if (strstr(attr, ATTR_PARTITIONS) != NULL) {
+					if (strstr(attr, OPTION_ALL_PARTITIONS) != NULL) {
 						dbg_parse("creation of partition nodes requested");
 						dev.partitions = DEFAULT_PARTITIONS_COUNT;
 					}
-					if (strstr(attr, ATTR_IGNORE_REMOVE) != NULL) {
+					if (strstr(attr, OPTION_IGNORE_REMOVE) != NULL) {
 						dbg_parse("remove event should be ignored");
 						dev.ignore_remove = 1;
 					}
@@ -292,18 +298,32 @@ static int namedev_parse(const char *fil
 			}
 
 			if (strcasecmp(temp2, FIELD_OPTIONS) = 0) {
-				if (strstr(temp3, ATTR_IGNORE_DEVICE) != NULL) {
+				if (strstr(temp3, OPTION_LAST_RULE) != NULL) {
+					dbg_parse("last rule to be applied for that device");
+					dev.last_rule = 1;
+				}
+				if (strstr(temp3, OPTION_IGNORE_DEVICE) != NULL) {
 					dbg_parse("device should be ignored");
 					dev.ignore_device = 1;
 				}
-				if (strstr(temp3, ATTR_IGNORE_REMOVE) != NULL) {
+				if (strstr(temp3, OPTION_IGNORE_REMOVE) != NULL) {
 					dbg_parse("remove event should be ignored");
 					dev.ignore_remove = 1;
 				}
-				if (strstr(temp3, ATTR_PARTITIONS) != NULL) {
+				if (strstr(temp3, OPTION_ALL_PARTITIONS) != NULL) {
 					dbg_parse("creation of partition nodes requested");
 					dev.partitions = DEFAULT_PARTITIONS_COUNT;
 				}
+				if (strstr(temp3, OPTION_NO_HOTPLUG) != NULL) {
+					dbg_parse("execution of hotplug programs supressed");
+					dev.no_hotplug = 1;
+				}
+				valid = 1;
+				continue;
+			}
+
+			if (strcasecmp(temp2, FIELD_HOTPLUG) = 0) {
+				strfieldcpy(dev.hotplug, temp3);
 				valid = 1;
 				continue;
 			}
@@ -345,7 +365,7 @@ error:
 	return retval;
 }
 
-int namedev_init(void)
+int rules_init(void)
 {
 	struct stat stats;
 	int retval;
@@ -354,14 +374,14 @@ int namedev_init(void)
 		return -1;
 
 	if ((stats.st_mode & S_IFMT) != S_IFDIR)
-		retval = namedev_parse(udev_rules_filename, NULL);
+		retval = rules_parse(NULL, udev_rules_filename);
 	else
-		retval = call_foreach_file(namedev_parse, udev_rules_filename, RULEFILE_SUFFIX, NULL);
+		retval = call_foreach_file(rules_parse, NULL, udev_rules_filename, RULEFILE_SUFFIX);
 
 	return retval;
 }
 
-void namedev_close(void)
+void rules_close(void)
 {
 	struct config_device *dev;
 
=== udev.8.in 1.78 vs edited ==--- 1.78/udev.8.in	2005-02-13 22:03:06 +01:00
+++ edited/udev.8.in	2005-02-28 05:38:24 +01:00
@@ -98,9 +98,8 @@ Every rule consists of a list of comma s
 .sp
 where fields are:
 .TP
-.B BUS
-Match the bus type of the device.
-(The sysfs device bus must be able to be determined by a "device" symlink.)
+.B ACTION
+Match the event type.
 .TP
 .B KERNEL
 Match the kernel device name.
@@ -108,9 +107,16 @@ Match the kernel device name.
 .B SUBSYSTEM
 Match the kernel subsystem name.
 .TP
+.B ACTION
+Match the event action string.
+.TP
 .B DRIVER
 Match the kernel driver name.
 .TP
+.B BUS
+Match the bus type of the device.
+(The sysfs device bus must be able to be determined by a "device" symlink.)
+.TP
 .B ID
 Match the device number on the bus, like PCI bus id.
 .TP
@@ -178,6 +184,10 @@ This may be useful for removable media d
 change.
 .sp
 Multiple attributes may be separated by comma.
+.TP
+.B HOTPLUG
+programs to be added to a list to be excuted after node creation or removal.
+Identical keys will only be added once.
 .P
 .RB "The " NAME ", " SYMLINK ", " PROGRAM ", " OWNER " and " GROUP
 fields support simple printf-like string substitutions:
@@ -219,8 +229,14 @@ all remaining parts of the result string
 The name of a created temporary device node to provide access to the
 device from a external program.
 .TP
+.B %S
+The name of the subsystem.
+.TP
+.B %D
+The name of the device node.
+.TP
 .B %P
-The node name of the parent device.
+The name of the parent device node.
 .TP
 .BI %s{ filename }
 The content of a sysfs attribute.
@@ -301,15 +317,7 @@ is set if udev is configured to use the 
 want to follow that setting.
 .B DEVNAME
 is exported to make the name of the created node, or the name the network
-device is renamed to, available to the executed program. The programs in every
-directory are sorted in lexical order, while the directories are searched in
-the following order:
-.sp
-.nf
-/etc/dev.d/$(DEVNAME)/*.dev
-/etc/dev.d/$(SUBSYSTEM)/*.dev
-/etc/dev.d/default/*.dev
-.fi
+device is renamed to, available to the executed program.
 .SH "ENVIRONMENT"
 .P
 The following variables are read from the environment:
@@ -330,20 +338,11 @@ Overrides the default location of the
 .B udev
 config file.
 .TP
-.B UDEV_NO_DEVD
-The default behavior of
-.B udev
-is to execute programs in the
-.I /etc/dev.d/
-directory after device handling. If set,
-.B udev
-will skip this step.
 .SH "FILES"
 .nf
 /sbin/udev                           udev program
 /etc/udev/*                          udev config files
 /etc/hotplug.d/default/udev.hotplug  hotplug symlink to udev program
-/etc/dev.d/*                         programs invoked by udev
 .fi
 .SH "SEE ALSO"
 .BR udevinfo (8),
=== udev.c 1.104 vs edited ==--- 1.104/udev.c	2005-02-21 07:01:52 +01:00
+++ edited/udev.c	2005-02-28 17:40:45 +01:00
@@ -136,7 +136,7 @@ int main(int argc, char *argv[], char *e
 		/* disable all logging, as it's much too slow on some facilities */
 		udev_log = 0;
 
-		namedev_init();
+		rules_init();
 		retval = udev_start();
 		goto exit;
 	}
@@ -170,58 +170,74 @@ int main(int argc, char *argv[], char *e
 	if (udev_log)
 		setenv("UDEV_LOG", "1", 1);
 
-	udev_init_device(&udev, devpath, subsystem);
+	udev_init_device(&udev, devpath, subsystem, action);
 
 	if (udev.type = BLOCK || udev.type = CLASS || udev.type = NET) {
-		if (strcmp(action, "add") = 0) {
-			/* wait for sysfs and possibly add node */
-			dbg("udev add");
+		rules_init();
 
-			/* skip subsystems without "dev", but handle net devices */
-			if (udev.type != NET && subsystem_expect_no_dev(udev.subsystem)) {
-				dbg("don't care about '%s' devices", udev.subsystem);
-				goto hotplug;
-			}
+		if (strcmp(udev.action, "add") = 0) {
+			dbg("udev add");
 
+			/* wait for sysfs to populate */
 			snprintf(path, SYSFS_PATH_MAX, "%s%s", sysfs_path, udev.devpath);
+			path[SYSFS_PATH_MAX-1] = '\0';
 			class_dev = wait_class_device_open(path);
 			if (class_dev = NULL) {
 				dbg ("open class device failed");
 				goto hotplug;
 			}
 			dbg("opened class_dev->name='%s'", class_dev->name);
-
 			wait_for_class_device(class_dev, &error);
 
-			/* init rules */
-			namedev_init();
+			/* create a node for devices with a "dev" file */
+			if (!subsystem_expect_no_dev(udev.subsystem)) {
+				udev.devt = get_devt(class_dev);
+				if (!udev.devt) {
+					dbg("dev file expected, but not found");
+					sysfs_close_class_device(class_dev);
+					goto hotplug;
+				}
+			}
 
-			/* name, create node, store in db */
-			retval = udev_add_device(&udev, class_dev);
+			/* name device or possibly ignore event */
+			if (rules_get_name(&udev, class_dev) != 0) {
+				sysfs_close_class_device(class_dev);
+				goto hotplug;
+			}
 
+			udev_add_device(&udev, class_dev);
 			sysfs_close_class_device(class_dev);
-		} else if (strcmp(action, "remove") = 0) {
-			/* possibly remove a node */
+
+		} else if (strcmp(udev.action, "remove") = 0) {
 			dbg("udev remove");
 
 			/* skip subsystems without "dev" */
 			if (subsystem_expect_no_dev(udev.subsystem)) {
-				dbg("don't care about '%s' devices", udev.subsystem);
+				dbg("'%s' devices don't have device nodes", udev.subsystem);
 				goto hotplug;
 			}
 
+			/* get hotplug scripts or possibly ignore event */
+			if (rules_get_hotplug(&udev) != 0)
+				goto hotplug;
+
 			/* get node from db, remove db-entry, delete created node */
 			retval = udev_remove_device(&udev);
 		}
 
-		/* run dev.d/ scripts if we created/deleted a node or changed a netif name */
-		if (udev.devname[0] != '\0') {
+		/* execute hotplug scripts */
+		if (udev.devname[0] != '\0' && !udev.no_hotplug) {
+			struct name_entry *name_loop;
+
 			setenv("DEVNAME", udev.devname, 1);
-			if (udev_dev_d)
-				udev_multiplex_directory(&udev, DEVD_DIR, DEVD_SUFFIX);
+			rules_expand_hotplug_list(&udev);
+
+			list_for_each_entry(name_loop, &udev.hotplug_list, node)
+				execute_command(&udev, name_loop->name);
 		}
+
 	} else if (udev.type = PHYSDEV) {
-		if (strcmp(action, "add") = 0) {
+		if (strcmp(udev.action, "add") = 0) {
 			/* wait for sysfs */
 			dbg("devices add");
 
@@ -236,12 +252,11 @@ int main(int argc, char *argv[], char *e
 			wait_for_devices_device(devices_dev, &error);
 
 			sysfs_close_device(devices_dev);
-		} else if (strcmp(action, "remove") = 0) {
+		} else if (strcmp(action, "remove") = 0)
 			dbg("devices remove");
-		}
-	} else {
-		dbg("unhandled");
-	}
+
+	} else
+		dbg("don't care");
 
 hotplug:
 	if (udev_hotplug_d && managed_event)
=== udev.h 1.87 vs edited ==--- 1.87/udev.h	2005-02-21 06:48:12 +01:00
+++ edited/udev.h	2005-02-28 12:38:48 +01:00
@@ -4,6 +4,7 @@
  * Userspace devfs
  *
  * Copyright (C) 2003 Greg Kroah-Hartman <greg@kroah.com>
+ * Copyright (C) 2003-2005 Kay Sievers <kay.sievers@vrfy.org>
  *
  *	This program is free software; you can redistribute it and/or modify it
  *	under the terms of the GNU General Public License as published by the
@@ -31,7 +32,9 @@
 #define ALARM_TIMEOUT			120
 #define COMMENT_CHARACTER		'#'
 
+#define LINE_SIZE			512
 #define NAME_SIZE			256
+#define PROGRAM_SIZE			128
 #define USER_SIZE			32
 
 #define ACTION_SIZE			32
@@ -39,16 +42,16 @@
 #define SUBSYSTEM_SIZE			32
 #define SEQNUM_SIZE			32
 
-#define LINE_SIZE			512
-
-#define DEVD_DIR			"/etc/dev.d"
-#define DEVD_SUFFIX			".dev"
-
 #define HOTPLUGD_DIR			"/etc/hotplug.d"
 #define HOTPLUG_SUFFIX			".hotplug"
 
 #define DEFAULT_PARTITIONS_COUNT	15
 
+struct name_entry {
+	struct list_head node;
+	char name[NAME_SIZE];
+};
+
 enum device_type {
 	UNKNOWN,
 	CLASS,
@@ -58,22 +61,28 @@ enum device_type {
 };
 
 struct udevice {
+	char action[ACTION_SIZE];
 	char devpath[DEVPATH_SIZE];
 	char subsystem[SUBSYSTEM_SIZE];
 
 	char name[NAME_SIZE];
+	char devname[NAME_SIZE];
 	char symlink[NAME_SIZE];
 	char owner[USER_SIZE];
 	char group[USER_SIZE];
 	mode_t mode;
-	char type;
+	enum device_type type ;
 	dev_t devt;
 
-	char devname[NAME_SIZE];
 	char tmp_node[NAME_SIZE];
 	int partitions;
 	int ignore_remove;
-	int config_line;
+	int no_hotplug;
+	int last_rule;
+
+	struct list_head hotplug_list;
+
+	unsigned int config_line;
 	char config_file[NAME_SIZE];
 	char bus_id[SYSFS_NAME_LEN];
 	char program_result[NAME_SIZE];
@@ -95,7 +104,6 @@ extern char udev_db_path[PATH_MAX+NAME_M
 extern char udev_config_filename[PATH_MAX+NAME_MAX];
 extern char udev_rules_filename[PATH_MAX+NAME_MAX];
 extern int udev_log;
-extern int udev_dev_d;
 extern int udev_hotplug_d;
 
 #endif
=== udev_add.c 1.95 vs edited ==--- 1.95/udev_add.c	2005-02-21 05:45:03 +01:00
+++ edited/udev_add.c	2005-02-28 04:17:44 +01:00
@@ -39,7 +39,6 @@
 #include "libsysfs/sysfs/libsysfs.h"
 #include "udev.h"
 #include "udev_utils.h"
-#include "udev_sysfs.h"
 #include "udev_version.h"
 #include "logging.h"
 #include "namedev.h"
@@ -272,17 +271,6 @@ int udev_add_device(struct udevice *udev
 {
 	char *pos;
 	int retval = 0;
-
-	if (udev->type = BLOCK || udev->type = CLASS) {
-		udev->devt = get_devt(class_dev);
-		if (!udev->devt) {
-			dbg("no dev-file found, do nothing");
-			return 0;
-		}
-	}
-
-	if (namedev_name_device(udev, class_dev) != 0)
-		return 0;
 
 	dbg("adding name='%s'", udev->name);
 
=== udev_config.c 1.31 vs edited ==--- 1.31/udev_config.c	2005-01-04 21:37:01 +01:00
+++ edited/udev_config.c	2005-02-28 04:17:44 +01:00
@@ -46,7 +46,6 @@ char udev_db_path[PATH_MAX+NAME_MAX];
 char udev_rules_filename[PATH_MAX+NAME_MAX];
 char udev_config_filename[PATH_MAX+NAME_MAX];
 int udev_log;
-int udev_dev_d;
 int udev_hotplug_d;
 
 
@@ -72,11 +71,6 @@ static void init_variables(void)
 	strcpy(udev_rules_filename, UDEV_RULES_FILE);
 
 	udev_log = string_is_true(UDEV_LOG_DEFAULT);
-
-	udev_dev_d = 1;
-	env = getenv("UDEV_NO_DEVD");
-	if (env && string_is_true(env))
-		udev_dev_d = 0;
 
 	udev_hotplug_d = 1;
 	env = getenv("UDEV_NO_HOTPLUGD");
=== udev_multiplex.c 1.25 vs edited ==--- 1.25/udev_multiplex.c	2004-11-25 01:55:54 +01:00
+++ edited/udev_multiplex.c	2005-02-28 04:27:29 +01:00
@@ -31,11 +31,10 @@
 #include "udev_utils.h"
 #include "logging.h"
 
-static int run_program(const char *filename, void *data)
+static int run_program(struct udevice *udev, const char *filename)
 {
 	pid_t pid;
 	int fd;
-	struct udevice *udev = data;
 
 	dbg("running %s", filename);
 
@@ -89,7 +88,7 @@ void udev_multiplex_directory(struct ude
 			if (strcmp(devname, udev->subsystem) != 0) {
 				snprintf(dirname, PATH_MAX, "%s/%s", basedir, devname);
 				dirname[PATH_MAX-1] = '\0';
-				call_foreach_file(run_program, dirname, suffix, udev);
+				call_foreach_file(run_program, udev, dirname, suffix);
 			}
 
 			temp[0] = '/';
@@ -101,16 +100,16 @@ void udev_multiplex_directory(struct ude
 	if (udev->name[0] != '\0') {
 		snprintf(dirname, PATH_MAX, "%s/%s", basedir, udev->name);
 		dirname[PATH_MAX-1] = '\0';
-		call_foreach_file(run_program, dirname, suffix, udev);
+		call_foreach_file(run_program, udev, dirname, suffix);
 	}
 
 	if (udev->subsystem[0] != '\0') {
 		snprintf(dirname, PATH_MAX, "%s/%s", basedir, udev->subsystem);
 		dirname[PATH_MAX-1] = '\0';
-		call_foreach_file(run_program, dirname, suffix, udev);
+		call_foreach_file(run_program, udev, dirname, suffix);
 	}
 
 	snprintf(dirname, PATH_MAX, "%s/default", basedir);
 	dirname[PATH_MAX-1] = '\0';
-	call_foreach_file(run_program, dirname, suffix, udev);
+	call_foreach_file(run_program, udev, dirname, suffix);
 }
=== udev_start.c 1.29 vs edited ==--- 1.29/udev_start.c	2005-02-10 10:26:09 +01:00
+++ edited/udev_start.c	2005-02-28 04:17:44 +01:00
@@ -35,6 +35,8 @@
 #include <unistd.h>
 
 #include "libsysfs/sysfs/libsysfs.h"
+#include "namedev.h"
+#include "udev_sysfs.h"
 #include "logging.h"
 #include "udev_utils.h"
 #include "list.h"
@@ -96,7 +98,7 @@ static int add_device(const char *path, 
 
 	devpath = &path[strlen(sysfs_path)];
 
-	/* set environment for callouts and dev.d/ */
+	/* set environment for callouts and hotplug programs */
 	setenv("DEVPATH", devpath, 1);
 	setenv("SUBSYSTEM", subsystem, 1);
 
@@ -108,15 +110,32 @@ static int add_device(const char *path, 
 		return -ENODEV;
 	}
 
-	udev_init_device(&udev, devpath, subsystem);
+	udev_init_device(&udev, devpath, subsystem, "add");
+
+	/* create a node for devices with a "dev" file */
+	if (!subsystem_expect_no_dev(udev.subsystem)) {
+		udev.devt = get_devt(class_dev);
+		if (!udev.devt) {
+			dbg("dev file expected, but not found");
+			goto exit;
+		}
+	}
+
+	if (rules_get_name(&udev, class_dev) != 0)
+		goto exit;
+
 	udev_add_device(&udev, class_dev);
 
-	/* run dev.d/ scripts if we created a node or changed a netif name */
-	if (udev_dev_d && udev.devname[0] != '\0') {
+	/* execute hotplug scripts */
+	if (udev.devname[0] != '\0' && !udev.no_hotplug) {
+		struct name_entry *name_loop;
+
 		setenv("DEVNAME", udev.devname, 1);
-		udev_multiplex_directory(&udev, DEVD_DIR, DEVD_SUFFIX);
+		list_for_each_entry(name_loop, &udev.hotplug_list, node)
+			execute_command(&udev, name_loop->name);
 	}
 
+exit:
 	sysfs_close_class_device(class_dev);
 
 	return 0;
@@ -280,7 +299,7 @@ static void udev_scan_class(void)
 
 int udev_start(void)
 {
-	/* set environment for callouts and dev.d/ */
+	/* set environment for callouts and hotplug programs */
 	setenv("ACTION", "add", 1);
 	setenv("UDEV_START", "1", 1);
 
=== udev_utils.c 1.32 vs edited ==--- 1.32/udev_utils.c	2005-02-21 07:01:52 +01:00
+++ edited/udev_utils.c	2005-02-28 04:40:45 +01:00
@@ -29,6 +29,7 @@
 #include <dirent.h>
 #include <sys/stat.h>
 #include <sys/mman.h>
+#include <sys/wait.h>
 #include <sys/utsname.h>
 
 #include "udev.h"
@@ -37,11 +38,12 @@
 #include "list.h"
 
 
-int udev_init_device(struct udevice *udev, const char* devpath, const char *subsystem)
+int udev_init_device(struct udevice *udev, const char* devpath, const char *subsystem, const char *action)
 {
 	char *pos;
 
 	memset(udev, 0x00, sizeof(struct udevice));
+	INIT_LIST_HEAD(&udev->hotplug_list);
 
 	if (devpath) {
 		strfieldcpy(udev->devpath, devpath);
@@ -49,6 +51,8 @@ int udev_init_device(struct udevice *ude
 	}
 	if (subsystem)
 		strfieldcpy(udev->subsystem, subsystem);
+	if (action)
+		strfieldcpy(udev->action, action);
 
 	if (strcmp(udev->subsystem, "block") = 0)
 		udev->type = BLOCK;
@@ -262,13 +266,7 @@ void no_trailing_slash(char *path)
 		path[--len] = '\0';
 }
 
-struct name_entry {
-	struct list_head node;
-	char name[NAME_SIZE];
-};
-
-/* sort files in lexical order */
-static int name_list_add(struct list_head *name_list, const char *name, int sort)
+int name_list_add(struct list_head *name_list, const char *name, int sort)
 {
 	struct name_entry *loop_name;
 	struct name_entry *new_name;
@@ -291,11 +289,75 @@ static int name_list_add(struct list_hea
 
 	strfieldcpy(new_name->name, name);
 	list_add_tail(&new_name->node, &loop_name->node);
+
+	return 0;
+}
+
+int execute_command(struct udevice *udev, const char *command)
+{
+	int retval;
+	pid_t pid;
+	char arg[PROGRAM_SIZE];
+	char *argv[(PROGRAM_SIZE / 2) + 1];
+	char *pos;
+	int fd;
+	int i;
+
+	strfieldcpy(arg, command);
+	i = 0;
+	if (strchr(command, ' ')) {
+		pos = arg;
+		while (pos != NULL) {
+			if (pos[0] = '\'') {
+				/* don't separate if in apostrophes */
+				pos++;
+				argv[i] = strsep(&pos, "\'");
+				while (pos && pos[0] = ' ')
+					pos++;
+			} else {
+				argv[i] = strsep(&pos, " ");
+			}
+			dbg("arg[%i] '%s'", i, argv[i]);
+			i++;
+		}
+		argv[i] =  NULL;
+		dbg("execute '%s' with parsed arguments", arg);
+	} else {
+		argv[0] = arg;
+		argv[1] = udev->subsystem;
+		argv[2] = NULL;
+		dbg("execute '%s' with subsystem '%s' argument", arg, argv[1]);
+	}
+
+	pid = fork();
+	switch (pid) {
+	case 0:
+		/* child */
+		fd = open("/dev/null", O_RDWR);
+		if ( fd >= 0) {
+			dup2(fd, STDOUT_FILENO);
+			dup2(fd, STDIN_FILENO);
+			dup2(fd, STDERR_FILENO);
+		}
+		close(fd);
+
+		retval = execv(arg, argv);
+		dbg("exec of child failed");
+		_exit(1);
+	case -1:
+		dbg("fork of child failed");
+		break;
+		return -1;
+	default:
+		waitpid(pid, NULL, 0);
+	}
+
 	return 0;
 }
 
 /* calls function for every file found in specified directory */
-int call_foreach_file(file_fnct_t fnct, const char *dirname, const char *suffix, void *data)
+int call_foreach_file(int (*handler_function)(struct udevice *udev, const char *string),
+		      struct udevice *udev, const char *dirname, const char *suffix)
 {
 	struct dirent *ent;
 	DIR *dir;
@@ -338,7 +400,7 @@ int call_foreach_file(file_fnct_t fnct, 
 		snprintf(filename, NAME_SIZE, "%s/%s", dirname, loop_file->name);
 		filename[NAME_SIZE-1] = '\0';
 
-		fnct(filename, data);
+		handler_function(udev, filename);
 
 		list_del(&loop_file->node);
 		free(loop_file);
=== udev_utils.h 1.23 vs edited ==--- 1.23/udev_utils.h	2005-02-21 06:48:12 +01:00
+++ edited/udev_utils.h	2005-02-28 04:37:18 +01:00
@@ -76,7 +76,7 @@ do { \
 # define asmlinkage	/* nothing */
 #endif
 
-extern int udev_init_device(struct udevice *udev, const char* devpath, const char *subsystem);
+extern int udev_init_device(struct udevice *udev, const char* devpath, const char *subsystem, const char *action);
 extern int kernel_release_satisfactory(unsigned int version, unsigned int patchlevel, unsigned int sublevel);
 extern int create_path(const char *path);
 extern int parse_get_pair(char **orig_string, char **left, char **right);
@@ -85,8 +85,10 @@ extern int file_map(const char *filename
 extern void file_unmap(char *buf, size_t bufsize);
 extern size_t buf_get_line(const char *buf, size_t buflen, size_t cur);
 extern void no_trailing_slash(char *path);
-typedef int (*file_fnct_t)(const char *filename, void *data);
-extern int  call_foreach_file(file_fnct_t fnct, const char *dirname,
-			      const char *suffix, void *data);
+extern int name_list_add(struct list_head *name_list, const char *name, int sort);
+
+extern int execute_command(struct udevice *udev, const char *command);
+extern int call_foreach_file(int (*handler_function)(struct udevice *udev, const char *string),
+			     struct udevice *udev, const char *dirname, const char *suffix);
 
 #endif
=== udevtest.c 1.24 vs edited ==--- 1.24/udevtest.c	2005-02-21 05:45:04 +01:00
+++ edited/udevtest.c	2005-02-28 04:17:44 +01:00
@@ -85,13 +85,13 @@ int main(int argc, char *argv[], char *e
 	info("looking at '%s'", devpath);
 
 	/* initialize the naming deamon */
-	namedev_init();
+	rules_init();
 
 	if (argc = 3)
 		subsystem = argv[2];
 
 	/* fill in values and test_run flag*/
-	udev_init_device(&udev, devpath, subsystem);
+	udev_init_device(&udev, devpath, subsystem, "add");
 
 	/* skip subsystems without "dev", but handle net devices */
 	if (udev.type != NET && subsystem_expect_no_dev(udev.subsystem)) {



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Roman Kagan]

On Mon, Feb 28, 2005 at 07:41:41PM +0100, Kay Sievers wrote:
> I've changes the HOTPLUG key to be able to read a whole subdirectory
> with a wildcard instead of only one file. The following three rules will
> emulate the dev.d/ directory handling we currently have compiled in:
> 
>   HOTPLUG="/etc/dev.d/%D/*.dev"
>   HOTPLUG="/etc/dev.d/%S/*.dev"
>   HOTPLUG="/etc/dev.d/default/*.dev"

Given that this is a compatibility stuff, can't it be handled
externally, without bloating udev?  E.g.

HOTPLUG="/usr/bin/run-parts /etc/dev.d/default"

or even simply

HOTPLUG="sh -c 'for f in /etc/dev.d/default/*.dev; do [ -x \$f ] && \$f; done'"

Another suggestion is of a syntactic sugar kind: would it be too hard to
implement key substitution in actions with a generic syntax, rather than
adding %-conversion specifier for each possible substitution, e.g.

HOTPLUG="foo $SUBSYSTEM $SYSFS{bar} $ENV{baz}"

Cheers,
  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

On Feb 28, Roman Kagan <rkagan@mail.ru> wrote:

> Given that this is a compatibility stuff, can't it be handled
It's not "compatibility stuff" until there is a plan to fully replace
dev.d with something else, and I do not see one.
And if there is a complete replacement then dev.d could be as well
scrapped, since there are just a few users of it.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: The Next Generation

[Kay Sievers]

On Mon, 2005-02-28 at 22:11 +0300, Roman Kagan wrote:
>On Mon, Feb 28, 2005 at 07:41:41PM +0100, Kay Sievers wrote:
>> I've changes the HOTPLUG key to be able to read a whole subdirectory
>> with a wildcard instead of only one file. The following three rules will
>> emulate the dev.d/ directory handling we currently have compiled in:
>> 
>>   HOTPLUG="/etc/dev.d/%D/*.dev"
>>   HOTPLUG="/etc/dev.d/%S/*.dev"
>>   HOTPLUG="/etc/dev.d/default/*.dev"
>
>Given that this is a compatibility stuff, can't it be handled
>externally, without bloating udev?  E.g.
>
>HOTPLUG="/usr/bin/run-parts /etc/dev.d/default"

>or even simply
>
>HOTPLUG="sh -c 'for f in /etc/dev.d/default/*.dev; do [ -x \$f ] && \$f; done'"

Sure, something like that should work too. It was easy to do this inside
of udev, don't know what's better here. The internal one can sort out
doubles, from all all the keys, but that isn't a required feature...

>Another suggestion is of a syntactic sugar kind: would it be too hard to
>implement key substitution in actions with a generic syntax, rather than
>adding %-conversion specifier for each possible substitution, e.g.
>
>HOTPLUG="foo $SUBSYSTEM $SYSFS{bar} $ENV{baz}"

No, that is not really hard. I thought about something like this too, if
we are running out of nice characters. :)

It is nicer to read, yes. But renaming some of the keys would be nice
too, like:
  ADD_SYMLINK, ADD_HOTPLUG, MATCH_ACTION, SET_GROUP, SET_MODE, SET_NAME

so the key can tell you what it does in reality. Today you need to know
that KERNEL= is a match instruction, SYMLINK= will add something to a
list and GROUP= will override any value. Sometimes, we should do all
that. :)

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Chris Larson]

* Kay Sievers (kay.sievers@vrfy.org) wrote:
> On Mon, 2005-02-28 at 22:11 +0300, Roman Kagan wrote:
> >On Mon, Feb 28, 2005 at 07:41:41PM +0100, Kay Sievers wrote:
> >> I've changes the HOTPLUG key to be able to read a whole subdirectory
> >> with a wildcard instead of only one file. The following three rules will
> >> emulate the dev.d/ directory handling we currently have compiled in:
> >> 
> >>   HOTPLUG="/etc/dev.d/%D/*.dev"
> >>   HOTPLUG="/etc/dev.d/%S/*.dev"
> >>   HOTPLUG="/etc/dev.d/default/*.dev"
> >
> >Given that this is a compatibility stuff, can't it be handled
> >externally, without bloating udev?  E.g.
> >
> >HOTPLUG="/usr/bin/run-parts /etc/dev.d/default"
> 
> >or even simply
> >
> >HOTPLUG="sh -c 'for f in /etc/dev.d/default/*.dev; do [ -x \$f ] && \$f; done'"
> 
> Sure, something like that should work too. It was easy to do this inside
> of udev, don't know what's better here. The internal one can sort out
> doubles, from all all the keys, but that isn't a required feature...
> 
> >Another suggestion is of a syntactic sugar kind: would it be too hard to
> >implement key substitution in actions with a generic syntax, rather than
> >adding %-conversion specifier for each possible substitution, e.g.
> >
> >HOTPLUG="foo $SUBSYSTEM $SYSFS{bar} $ENV{baz}"
> 
> No, that is not really hard. I thought about something like this too, if
> we are running out of nice characters. :)
> 
> It is nicer to read, yes. But renaming some of the keys would be nice
> too, like:
>   ADD_SYMLINK, ADD_HOTPLUG, MATCH_ACTION, SET_GROUP, SET_MODE, SET_NAME
> 
> so the key can tell you what it does in reality. Today you need to know
> that KERNEL= is a match instruction, SYMLINK= will add something to a
> list and GROUP= will override any value. Sometimes, we should do all
> that. :)

I really like that idea.  Far more intuitive.
--
Chris Larson - kergoth at handhelds dot org
Linux Software Systems Engineer - clarson at ti dot com
Core Developer/Architect - BitBake, OpenEmbedded, OpenZaurus


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Kay Sievers]

On Mon, 2005-02-28 at 20:49 +0100, Marco d'Itri wrote:
>On Feb 28, Roman Kagan <rkagan@mail.ru> wrote:
>
>> Given that this is a compatibility stuff, can't it be handled
>It's not "compatibility stuff" until there is a plan to fully replace
>dev.d with something else, and I do not see one.

Sure, I can see it clearly. It already works nicely on my box and is
more than 3 times faster. :)
The dev.d/ stuff can be replaced by a rule and acts by default like our
current udev. And systems that don't need it, just remove these rules,
add a few HOTPLUG= keys and get the big performance hit.

>And if there is a complete replacement then dev.d could be as well
>scrapped, since there are just a few users of it.

That decision is up to the system integrators. dev.d/ is causing the
biggest udev problems today, so I expect it will no longer be used in a
very short time if we provide a good alternative to it.

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

On Feb 28, Kay Sievers <kay.sievers@vrfy.org> wrote:

> It is nicer to read, yes. But renaming some of the keys would be nice
> too, like:
>   ADD_SYMLINK, ADD_HOTPLUG, MATCH_ACTION, SET_GROUP, SET_MODE, SET_NAME
Please don't... this would make rules files excessively verbose, and I
believe that it's already quite clear which rules are conditions and
which one are actions.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: The Next Generation

[Kay Sievers]

On Mon, 2005-02-28 at 21:50 +0100, Marco d'Itri wrote:
>On Feb 28, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> It is nicer to read, yes. But renaming some of the keys would be nice
>> too, like:
>>   ADD_SYMLINK, ADD_HOTPLUG, MATCH_ACTION, SET_GROUP, SET_MODE, SET_NAME
>Please don't... this would make rules files excessively verbose, and I
>believe that it's already quite clear which rules are conditions and
>which one are actions.

Don't worry, there are no plans at the moment. :)
But I still think that it would be nice to be able to read the kind of
instruction from the key. Or we may allow '=' and get:
  BUS="ide", KERNEL="hda", NAME="hda", SYMLINK="disk"?

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Erik van Konijnenburg]

On Mon, Feb 28, 2005 at 09:50:22PM +0100, Marco d'Itri wrote:
> On Feb 28, Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > It is nicer to read, yes. But renaming some of the keys would be nice
> > too, like:
> >   ADD_SYMLINK, ADD_HOTPLUG, MATCH_ACTION, SET_GROUP, SET_MODE, SET_NAME
> Please don't... this would make rules files excessively verbose, and I
> believe that it's already quite clear which rules are conditions and
> which one are actions.

Once you're fully familiar with the rules, yes.  However, when I was
learning the rules, a bit of syntactic sugar would have helped.

How about: "IF the separator is an arrow instead of a comma,
then the conditions must be on the left and the actions on the right"

	KERNEL="js[0-9]*" => NAME="input/%k", MODE="0664"

It's less verbose, backward compatible, and allows udev to catch
some misunderstandings from a beginning rule author.

Regards,
Erik


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Roman Kagan]

On Mon, Feb 28, 2005 at 09:37:29PM +0100, Kay Sievers wrote:
> On Mon, 2005-02-28 at 22:11 +0300, Roman Kagan wrote:
> >HOTPLUG="sh -c 'for f in /etc/dev.d/default/*.dev; do [ -x \$f ] && \$f; done'"
> 
> Sure, something like that should work too. It was easy to do this inside
> of udev, don't know what's better here.

My point was that you wanted udev to be as ligthweight as possible on
one hand, but kept adding functionality, which is not absolutely
necessary, on the other.

> >Another suggestion is of a syntactic sugar kind: would it be too hard to
> >implement key substitution in actions with a generic syntax, rather than
> >adding %-conversion specifier for each possible substitution, e.g.
> >
> >HOTPLUG="foo $SUBSYSTEM $SYSFS{bar} $ENV{baz}"
> 
> No, that is not really hard. I thought about something like this too, if
> we are running out of nice characters. :)

The problem with "nice characters" is that each one need additional
doctumentation, too.

> It is nicer to read, yes. But renaming some of the keys would be nice
> too, like:
>   ADD_SYMLINK, ADD_HOTPLUG, MATCH_ACTION, SET_GROUP, SET_MODE, SET_NAME
> 
> so the key can tell you what it does in reality. Today you need to know
> that KERNEL= is a match instruction, SYMLINK= will add something to a
> list and GROUP= will override any value.

I think that's the distinction between keys to be matched against
(SUBSYSTEM, BUS, ID, etc.), and the actions to be taken (NAME, GROUP,
MODE, HOTPLUG), which was missing from the very beginning.  OTOH I'm
with Marco here, that making it too verbose doesn't make a lot of sense.
At most I would add a separator between keys and actions.

Cheers,
  Roman.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[Tobias Klauser]

On Mon, Feb 28, 2005 at 10:01:17PM +0100, Kay Sievers wrote:
> On Mon, 2005-02-28 at 21:50 +0100, Marco d'Itri wrote:
> >On Feb 28, Kay Sievers <kay.sievers@vrfy.org> wrote:
> >
> >> It is nicer to read, yes. But renaming some of the keys would be nice
> >> too, like:
> >>   ADD_SYMLINK, ADD_HOTPLUG, MATCH_ACTION, SET_GROUP, SET_MODE, SET_NAME
> >Please don't... this would make rules files excessively verbose, and I
> >believe that it's already quite clear which rules are conditions and
> >which one are actions.
> 
> Don't worry, there are no plans at the moment. :)
> But I still think that it would be nice to be able to read the kind of
> instruction from the key. Or we may allow '=' and get:
>   BUS="ide", KERNEL="hda", NAME="hda", SYMLINK="disk"?

That'd be very nice! As other people stated before, that's something quite
unusual about udev rules. In every programming language I can think of
and also in configuration files which use similar syntak '=' stands for
an assignment while '=' stands for a comparison. I guess it's not to hard
to implement and you could still keep the old behaviour in to have
backwards compatibility.

That change would make it much easier for "newbies" to start creating udev
rules.

Cheers, Tobias


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: The Next Generation

[David Brownell]

On Sunday 27 February 2005 3:34 pm, Kay Sievers wrote:
> On Sun, 2005-02-27 at 12:13 -0800, David Brownell wrote:
> >> I propose to make the udev architecture _the_ generic hotplug handler.
> >
> >Speaking as someone who's been content to let other folk drive the
> >evolution of hotplug for a while, I think it's not yet ready; but
> >I'm not averse to moving away from shell scripts as the main glue.
> >For the first generation, shell scripts were essential.
> >
> >Why do I say it's not yet ready?  One example:  I recently configured
> >an OpenEmbedded build to use udev (instead of devfs) and that grew
> >the boot time from about 5 seconds to about 3 minutes.  (With a very
> >generic kernel, and not many devices ...) Considering that the target
> >is closer to one second, "udev" clearly lost big.  And I've seen
> >corresponding udev thrashing from my SuSE 9.2 laptop; cutting battery
> >lifetime by 15% when I plug in a CF card (AND am lucky enough to notice
> >and find a way to kill the endless loop) is not good.  
> 
> It is a pcmcia device, right? The kernel does not work well here and it
> is not udev's fault. We talked to the kernel guys, cause with HAL we had
> the same trouble but got not very friendly responses and gave up on
> that. :(

CF is SFF-PCMCIA, yes.  Maybe PCMCIA will soon (finally!) get rid of
cardmgr and just be able to rely on the hotplug infrastructure, like
its CardBus sibling!  (Clearly there's no inherent need for a cardmgr,
since CardBus/PCI never needed one.  There are interesting patches in
the latest MM tree code...)


> But we did a lot of things over the last weeks to address the other
> problems. We have a new libsysfs now, which is much much faster, we have
> the "bus" link and don't need to look at all the files in sysfs to get
> the bus value the device is on and we have the driver and physical
> device in the environment and don't need to wait for something that will
> never show up in sysfs.
> We will get rules for the dev.d/ scripts which cuts the running time of
> udevstart to ~30% on my box.

Well 30% of three minutes is still about 50 seconds too long, but
that's certainly going in the correct direction!  :)

A better target would be about 0.5% of current, not 30% of current.


> And I sent a patch to change to the kobject core to be able to send the
> hotplug events after the default files in sysfs are created which will
> be much nicer than todays stat() looping udev processes.

I've seen the mail and patches flying around, certainly.  But the short
summary of all that is that 2.6.12 kernels (with matching udev) will be
better, but may still not quite be ready for the cutover you suggest.
Even for totally bleeding edge kamikaze systems ... and even if they
were, that means that it'd only be then (when, June?) that systems
using new infrastructure could start working that way.  Deploying that
stuff in robust systems would take longer.


> Let me know of any concrete problems with the newer kernel+udev versions
> you see on any of your boxes and I will see what I can do.

Next time I build a sytem, I'll keep an eye out for that.  Some of
that is probably that the OpenEmbedded stuff isn't smart about some
things it does.  (It took more than three extra minutes until I made
some simple changes to the udev setup...)


> It may even be an option for the embedded stuff to run a very tiny udev
> without a dependency on sysfs, cause all the basic informations (bus,
> driver, physical device, major/minor) are available with the hotplug
> environment now.

That might be interesting, but the early boot stuff is still not wholly
cooked either.  RAM is more scarce than on desktops, and it'd be nice
if the static device list could stay on a JFFS2 /dev and have only the
dynamically hotplugged devices (USB, CF, MMC, etc) be managed in RAMfs
by udev.  That sort of issue isn't entirely a udev thing, but design
choices in udev can complicate things there too.
 
- Dave



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel