Re: udev - question about current config format

[Greg KH <greg@kroah.com>]

On Fri, Jan 09, 2004 at 03:21:12PM +0100, Kay Sievers wrote:
> Hi Greg,
> I want to ask if we shouldn't change the namedev logic and
> make the rules generic and drop the different methods, cause
> the name for the method is mostly redundant.
> All what namedev does is applying a name when all device attributes
> are matching. It's not neccessary to to tell namedev to REPLACE,
> cause we always replace :)
> And why shouldn't we be able to combine a SYSFS_ attribute with the
> KERNEL name?

Hm, this sounds like a good idea...

> So here is a first idea:
> 
>   Every line in udev.rules consists only of a number of <key>="<value>"
> 
>     BUS           match with bus type
>     SYSFS_<file>  match with device attribute
>     ID/PLACE      match with bus "number" or "id"
>     KERNEL        match with kernel device name
>     RESULT        match with string returned by executed PROGRAM
>     PROGRAM       program to execute (true if exec returned with 0)

So don't match on a string value here?  Hm, would that make writing
programs easier?  At first glance it might.  It also might be a bit
easier to understand.

>     NAME          name for the device node
>     SYMLINK       one or more symlinks to NAME
> 
>   The rules are processed in the order they are given in the file.
>   Every configured KEY must match to apply the rule.
>   It would be more flexible cause we may use all possible keys in a rule.
>   It would be possible to exec the external program only for one specific
>   device to get its name.
>   We would be able to skip the expensive execution of the external
>   program if one of the other keys doesn't match.
> 
>     KERNEL="video*", PROGRAM="script.sh", NAME="%c"
>     SYSFS_model="V0815", PROGRAM="script.sh", NAME="%c"
>     SYSFS_model="V0815", KERNEL="video*", NAME="video/%n"
> 
> Do we need a bus PLACE? In current udev it seems we have the same
> processing for TOPOLOGY and NUMBER.

We do have the same processing, as I've never gotten around to fixing up
the topology logic.  I think we now have enough info in libsysfs to do
this, I just need to get the time...

But it might be redundant, as some buses (like usb) encode their
topology information in the bus number.  I don't know, what do other
people think about this?

At first glance, this is a big simplification, and yet is more flexible,
I like it :)

Due to your reorganization of the parser, it's not that hard to do this
either...

Any other people's opinions?

Have a patch to play with?

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
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