[Toybox] Pondering mdev...

[Rob Landley]

On 08/22/2013 11:17:17 PM, Isaac wrote:
> 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.

And hotplug wasn't originally supported by Linux. So?

> It was a directory set up by userspace (most files within which are  
> related
> to the kernel drivers.)

Statically, because there was no alternative circa Linux 2.2.

> 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?)

Some things used crazy paths, yes. The original devfs was probably the  
worst offender.

> And changing these paths can break some programs (the aforementioned
> case is one that makes OSS-based programs distro-specific).

And now the kernel's doing the same thing every time, so we know what  
the right answer is and programs that don't use the right path should  
be fixed.

Why is this not the correct answer to the problem, at least when  
designing something new?

(What does Android do here?)

> > >> 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.

Question: given 30 years of Moore's Law, does this actually buy us  
anything on a modern system?

Answer: further down, I see it does.

> 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...

Question: Can we scan it at runtime? If we know the module we need is  
somewhere under /lib/modules/$(uname -m) and it ends in .ko and we can  
identify it from the data in the module... why shouldn't we just do  
that?

Answer: Because Ubuntu manages to have 153 megabytes of crap in  
/lib/modules/$(uname -r) split up into 3300 separate files.

> 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.

Here I did:

# echo 1 > /proc/sys/vm/drop_caches;
# time cat $(find /lib/modules/$(uname -r) -name "*.ko") > /dev/null

real	0m17.345s
user	0m0.268s
sys	0m1.228s

So yeah, that's significant.

Looking at the man page, the .bin versions don't seem hugely useful.  
(If parsing a text file is a big deal, you're doing it wrong.)

Wow, do we really need all of these?

modules.alias modules.builtin modules.ccwmap modules.dep modules.devname
modules.ieee1394map modules.inputmap modules.isapnpmap modules.ofmap
modules.order modules.pcimap modules.seriomap modules.softdep  
modules.symbols
modules.usbmap

Even after reading the man page, I don't have a clear idea what depmod  
is doing if it's creating all that. alias, builtin, and dep I sort of  
understand. ccwmap?

ofmap... Open Firmware? On x86? isapnpmap... ISA plug and play? In  
2013? really? The PCI bus replaced ISA 20 years ago and they're  
creating a map of modules to support the old one? (I'm aware of legacy  
platform devices, but if you're building your CMOS clock driver a  
module something is _wrong_...)

<misspiggy>I don't understand any of this.</misspiggy>

> 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.

The problem with dynamically generating it is /lib/modules could be in  
squashfs. There's no guarantee we can write after system generation.  
I'd love for it to be transparent, but it would have to be under /var  
or something for that, and it could be a tmpfs...

> 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.)

I'm not a domain expert on modules. I build static kernels almost  
exclusively. This is an area where I'm happy to defer to the judgement  
of people who know what a good solution looks like.

I would like a simple solution, but I'm not wrapping my head around the  
problem domain well enough to be able to _discard_ a lot of the stuff  
it's doing. (It looks like depmod needs -b to work on a directory other  
than /lib/modules/$(uname -r). The concept of -P is kind of horrible,  
as is the existence of depmod.conf...)

> Thanks,
> Isaac Dunham

Rob