mdev

[Rob Landley]

On Sunday 19 April 2009 00:34:54 Vladimir Dronnikov wrote:
> > So you wouldn't be reusing any of the existing code in mdev?
>
> I would: make_device(), build_alias()

You want config file parsing for code that calls insmod?

Why?

> >> Simple. "mdev -s" doesn't enumerate /sys/devices/*. Some devices
> >
> > Ok, I'll bite.  How do you tell if devices under /sys/devices are char
> > devices or block devices?  You can't mknod without that information.
> >
> > I asked Greg Kroah-Hartman and Kay Sievers this information directly,
> > more than once.  They didn't provide a coherent answer.
>
> I don't care here of device type.

But the mknod syscall _does_.

> Let them be char.

According to http://www.lanana.org/docs/device-list/devices-2.6+.txt

major 1 minor 3 for char devices is /dev/null, and major 1 minor 3 for block 
devices is the third ram disk.  Major 4 minor 0 for char devices 
is /dev/tty0, and major 4 minor 0 for block devices is /dev/root.  Major 22 
minor 0 for char devices is the first "digiboard" serial port, major 22 minor 
0 for block devices is /dev/hdc (master device on second IDE controller).

It matters whether this is a char or a block device because major/minor by 
themself are _not_unique_, just like "which inode number" is unique without 
also specifying "which filesystem".

> If the system has  
> a device X (which is denoted by existance of a directory under
> /sys/devices/), I want mdev -s to account for it. Current mdev -s
> don't. If I rely on mdev -s to enumerate ALL devices, I'll fail here.

Which devices that only show up under /sys/devices (and not under /sys/class" 
are you missing?  Is this "completeness" or is this "actually a device you 
need, and not a device node for a USB bridge controller in case you needed to 
address one directly for some reason and didn't feel like using usbfs like 
everybody else"?

I vaguely recall asking Greg KH and Kay about this at OLS circa 2006, and the 
answer was that at the time everything that _isn't_ listed in /sys/block 
(or /sys/class/block, which is _stupid_ if you ask me) is a char device.  
(But I'm not _sure_ about that.)  And that the /sys/device nodes that weren't 
listed in /sys/class were the ones that aren't very interesting (I don't 
recall what the exact criteria were).

> >> And to load them you either
> >> need to issue modprobe "by hands", or (as I propose) rely on
> >> enumerating /sys/devices/* and $MODALIAS suport in mdev hotplug.
> >
> > You're using the words "enumerating" and "hotplug" in the same sentence.
>
> I'm not very fluent in english punctuation. The right sense is:
> enumeration in "mdev -s"; [and] $MODALIAS support in mdev hotplug.

Enumeration of _what_?  mdev -s shows you devices that have "dev" entries 
supplying a major and minor, meaning a driver is attached to that device and 
prepared to export a /dev entry for it.  If you haven't loaded the module 
yet, there won't be a "dev" entry for that device.

It's possible to teach the "list open files" command, lsof, to look for 
recently accessed files that are no longer open (the way "find . -anewer 
somefile").  The fact that the find command's "-amin" option is incredibly 
stupid (an exact match relative to the current time, not "everything within 
the last this many minutes"?  What were they smoking?) is no excuse to make 
lsof care about dentries instead of file handles, when that's not its job, 
instead of fixing "find".  (Or just putting up with the need to touch -t a 
temp file to humor the current find interface.)

> > pci:v00008086d000027DAsv00001028sd000001BDbc0Csc05i00
> >
> > Which looks like the data the hotplug thing I linked to earlier was
> > parsing...
>
> Current modprobe is happy with such arguments. We don't need any
> additional parsing.

Ok.

> >> > Right now, if you haven't got _either_ a device name _or_ a
> >> > major/minor to match on (neither of which you have if you have in the
> >> > absence of a device node), then there's no way for the current config
> >> > file to identify the device and thus attach behavior to its events.
> >>
> >> Wrong.
> >
> > I started my paragraph with "right now", and you tell me I'm wrong
> > because of code mdev hasn't got right now.  Interesting definition of
> > "wrong".
>
> The definition is right. Because current ("right now") mdev is capable
> of identifying a device by its subsystem (neither device _name_ nor
> maj:min). I explained it two lines later:
>
> ---
>
> >> net/.* - - @netif
>
> ---
>
> > You could add code to mdev to match on other environment variables it's
> > not currently looking at
>
> This is unneeded complication, may be, I'm rethinking now. The only
> envvars hotplug should reliably respect are $DEVPATH -> $MDEV,
> $ACTION, $SUBSYSTEM, $MODALIAS, $FIRMWARE. There is no reason to
> handle anything.

This week.

Keep in mind that SUBSYSTEM, MODALIAS, and FIRMWARE have all been added since 
mdev was first written.  Do you really think the kernel guys are done 
bloating their end of the interface?

> Currently only $MODALIAS isn't respected. And it IMHO should be
> intrinsic mdev behavior, so we could survive even with no mdev.conf at
> all.
>
> > They did adjust its assumptions.  The wrong way.
>
> Then may be reextact the right way code to mdev.c, and throw away the
> wrong one to mdev1.c, which can be changed until stabilized?

Is forking an applet and maintaining two copies of it _really_ the busybox 
way?

> > Because you haven't explained what's performing device enumeration (what
> > is finding devices that haven't got modules loaded, and requesting that
> > they be loaded?)
>
> # echo -n "add" >...uevent
>
> But this is very slow and cause hotplug storm. I admit it for _coldplug_.

Let's see if the "try loading all modules you find in /lib/modules and see 
which ones stick" method of performing enumeration is a reasonable approach 
before messing around with sysfs for this.

> >  And when I currently probe for this data from the code similar to
> > the enumeration code mdev already has, I get data that needs an extensive
> > parser referencing external data files (like the one in the hotplug code
> > I linked to) to make any sense of.
>
> No. No. No. modprobe will take it verbatim -- it is all in modules.aliases.
>
> >> A better alternative is IMHO a _solid_ hotplug helper capable of
> >> matching against environment variables (for they are the primary
> >> source of the event info).
> >
> > I'm all for it.  It should be a hotplug wrapper that calls mdev as
> > necessary, once it's handled modules and firmware and so on that mdev
> > isn't interested in.
>
> But notice then, that the rule which would match $MODALIAS, should be
> executed _any time_ an event is fired.

if [ ! -z "$MODALIAS" ]
then
  blah blah blah
fi

> So I see no gain in pushing the 
> intrinsic behavior into an external every-time-executing rule.

I see no gain in pushing the behavior into mdev.c, although I'm a little 
confused what you mean by "the rule which would match $MODALIAS".  You keep 
implying /etc/mdev.conf works in here somewhere, but I'm not seeing it...

> > Centralized means everything is done through it, potentially adding
> > arbitrary amounts of pluggable behavior for who knows what devices.
> >
> > I don't even know what you mean by "uniform".
>
> Uniform is for "configuration is applied to matching hotplug event
> targets (devices or not real devices, eth*, e.g.) thru mdev.conf
> rules".

Ok, please give me a potentially real world example where the current config 
file could significantly affect either $FIRMWARE or $MODALIAS handling for an 
actual device.  I'm curious.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds