"mdev: remove undocumented subsystem/devname matching hack" disaster.

[Piotr Karbowski]

On 04/02/2013 02:35 PM, Denys Vlasenko wrote:
> Mystery solved.
> The invocation which sets wrong ownership has $DEVNAME set:
>
> mdev[730]: 56.531462 ACTION:add SUBSYSTEM:sound DEVNAME:snd/controlC0
> DEVPATH:/devices/pci0000:00/0000:00:1b.0/sound/card0/controlC0
> mdev[730]: dev 116,5
> ...
>
> If $DEVNAME is set, we don't guess device name to be basename
> of $DEVPATH, we use $DEVNAME instead
> (because it looks like a better choice).
>
> "snd/controlC0" won't match "control.*       root:audio 660 =snd/"
> Last catch-all rule gets matched instead:
>
> mdev[730]: rule matched, line 111
> mdev[730]: mknod snd/controlC0 (116,5) 20660 0:0
> mdev[730]: running: /opt/mdev/helpers/catch-all
>
> This looks less than ideal, but I don't see immediate ways
> to improve it. Ideas?
>

Well, that's awkward, because mdev -s  see 'controlC0' but the mdev as 
hotplug agent after modprobe see it as snd/controlC0. I can imagine that 
this affect everything not only sound system. Would it be possible to 
restore how it was handled in older mdev? Otherwise that would require 
some heavy lifting regexes to handle it and some of the results can be 
far from desired result.

Woudn't it be better to 'basename' it? Because if the module is loaded 
or compiled in-kernel, it will be just 'controlC0', and I was pretty 
sure kernel never-ever provide subdir in DEVNAME, even the msr/cpuid 
support in kernel with help desc about /dev/cpu used to be created in 
bare /dev. The old mdev was using basename, and I see no real reason to 
not keep this as-it-was, what you think?

-- Piotr.