[Toybox] Pondering mdev...

[Isaac]

On Wed, Aug 21, 2013 at 02:37:32AM -0500, Rob Landley wrote:
> On 08/20/2013 11:24:59 PM, Isaac wrote:
> >On Tue, Aug 20, 2013 at 03:08:37PM -0500, Rob Landley wrote:
> I'm not saying there's no role remaining for mdev, I'm saying I
> don't know what that role is. If you have a better idea of the
> requirements, feel free to take point on this. (One thing I need to
> understand and don't is the udev/eudev split. What's the role for
> _eudev_ that devtmpfs doesn't do? The kernel guys were clearly
> aiming to obsolete udev to work around Kay Sievers after Linus
> chewed him out...)

(e)udev took over what hal-daemon did: report all the hardware.
X uses this for input device detection.
I think it's a pretty lame reason for including it.
 
> >or you use a set of paths that doesn't match the kernel default.
> 
> I agree you'd need a tool for that. I don't understand _why_ you'd
> want to do that, though. (Do you need a different set of paths under
> /proc or /sys and a tool that will adjust those? Why is /dev
> different when it's a kernel filesystem?)
 
/dev was originally not a kernel filesystem.
It was a directory set up by userspace (most files within which are related
to the kernel drivers.)
As such, there was some variation in paths, though not a whole lot
(do you have /dev/dsp or /dev/snd/dsp or something else?)
And changing these paths can break some programs (the aforementioned 
case is one that makes OSS-based programs distro-specific).

> >>
> >> At the design level: what is mdev needed for?
> >
> >The biggest reason to have a hotplug helper now is to autoload
> >modules.
> 
> According to kernel/kmod.c function call_modprobe() the kernel will call
> 
>   /sbin/modprobe -q -- $MODULE_NAME
> 
> So this isn't a hotplug event going to mdev, this is a
> call_usermodehelper_exec().
> 
> >I guess that means modprobe is higher up.
> >(Do we want to use depmod when we use modprobe? The alternative is
> >doing a
> >file-by-file search, which is more complicated.)
> 
> I suspect we need the functionality, and that funky char-major-%d-%d
> aliasing. That's the main difference between insmod and modprobe.
> Needing a separate demod database is iffy, presumably scanning a
> config file and the modules to find the right things to load
> shouldn't be that hard to do at runtime. (After the first module
> they should be cached...)

depmod is basically precaching it all.
To generate modules.alias, this should work:
find /lib/modules/`uname -r` -name '*.ko' | { while read M
  do
    for x in `modinfo -F alias`; do echo alias "$x `basename $M .ko`"; done
  done } >/lib/modules/`uname -r`/modules.alias

The C for which is trivially different from modinfo...

On first run, the full search can be extremely slow.
I tested with grep -r alias= <module_dir>, and got 38 seconds; 
subsequent runs ran 1.14 seconds.
And that's not really ideal for a fast boot; I count 125 "modalias" files,
with 67 unique device aliases.

Meanwhile, a search of modules.alias is ~0.02 seconds.

Or would this essentially "run depmod if it hasn't been run yet"?
If so, I'm fine with that. But it would be nice to be _able_ to have all
the caches generated beforehand.

I'm attaching resolve_modalias.c; this is a toy that was mainly intended
as a demonstration of the method of searching.
It does an exhaustive search, because I wanted to get both drivers for my
wireless card (even if a module is blacklisted, it ends up in modules.alias)
And it's not really ideal in other ways (starting a linked list with an empty
entry, etc.)


Thanks,
Isaac Dunham
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resolve_modalias.c
Type: text/x-csrc
Size: 1927 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20130822/856349cc/attachment-0007.c>