[Toybox] depmod & modprobe?

enh enh at google.com
Fri Mar 6 17:49:04 PST 2020


On Thu, Mar 5, 2020 at 10:17 AM Rob Landley <rob at landley.net> wrote:
>
>
>
> On 3/5/20 12:11 AM, scsijon wrote:
> >
> > On 05/03/20 14:29, Rob Landley wrote:
> >> On 3/4/20 12:28 AM, scsijon wrote:
> >>> I was wondering, since you've added most of the set (insmod, rmmod, lsmod,
> >>> modprobe, modinfo, depmod), why you left the last two out as it would allow the
> >>> removal of a package.
> >>
> >> Because nobody's poked me about them yet?
> >
> > :-) consider yourself poked, please, for both.
>
> I'm trying to put out a release. I'm hoping to get to the cp -D thing today
> (yes, I acknowledge having been poked, it's allocating two things without
> freeing them so it can modify the argument strings and I want to understand
> why), I've gotta finish researching the ping ttl stuff to see if I can do it
> without iovec, I need to rebuild all the target binaries which means getting
> mcm-buildall.sh and "make root" working right again, it would be really nice if
> I could get toysh to run the mkroot init script, and I'm currently expecting to
> fly back to Japan maybe on the 17th which gives me a deadline for all this. (And
> the reason I'm flying back _that_ late is Jury duty on the 11th, although I've
> never been selected to actually serve before I still have to show up to the
> rejection panel.)
>
> I'll throw it on the todo heap. :)
>
> >> There's a modprobe in pending.and depmod only matters if you want a modules.dep
> >> file, which seems deeply silly to me because you can just read the modules files
> >> live to get the information from them? (We don't have a lib.dep file for all the
> >> libraries under /usr/lib and such, we just search them live because it doesn't
> >> take long at all.)
> >>
> >
> > The kernel seems to want them, and we serve the kernel what it wants!
>
> How does the kernel care about a userspace index file which can be generated on
> the fly via search path and readelf plumbing (the way *.a and *.so files do it
> at compile time and at dynamic link runtime)?
>
> (Modules are basically the kernel's libraries.)
>
> > Or is
> > there a need for a depmod replacement that can be linked as that and does it all
> > on command?
>
> I was thinking of putting the plumbing in lib/ so the commands could share it,
> sure. (Or doing the ps.c trick of having multiple commands in the same file so
> they share the plumbing that way.)
>
> >>> You should (?maybe) only need eudev to build with, rather
> >>> than have to include kmod and not use toybox's commands.
> >
> > I'd love to be able to remove the kmod-eudev / kmod-udev /
> > module-init-tools-udev pairs, and we do use kernel modules as we work with a lot
> > of very mixed up laptops and desktops, let alone ex-windows tablets and others
> > in puppylinux and easyos nowadays.
>
> Ok, you understand the use case here and I don't, so I can presumably get some
> guidance here on what the code needs to _do_.
>
> I do not know what success looks like here well enough to implement the designs
> I can easily sketch out, because I don't use that part of it very often.
>
> >> I'm the guy who originally wrote mdev way back when,
> >
> > seem to remember that being mentioned before, strangely it's still available and
> > there are a number of people reckon it's still better, just limited by the
> > desktop problems, maybe you could/should start to think about a enhanced
> > replacement for toybox :-)
>
> Oh I am. I'm not planning to just copy whatever extensions busybox has done on
> top of my work since I stopped paying attention (although compatibility with
> that one is nice, it's more or less a "standard".)
>
> But again, same issue: _what_ desktop problems? What do you need that busybox
> mdev doesn't do well today?
>
> > so it shouldn't be a
> >> surprise I'm not a big fan of eudev.
> >
> > it's better than a couple of alternatives that have appeared (and thankfully
> > dissapeared again) over the years
>
> Does systemd _officially_ play the katamari damacy theme song yet, or is that
> still just implied?
>
> Rob
>
> P.S. I don't think Android uses modules either? But I haven't dug into it, their
> kernel stuff changes every few years...

historically, no. Google devices didn't use modules and the party line
was that they were a bad idea, but grudgingly supported because SoC
vendors/OEMs liked them.

now it's part of the plan of record for getting to a world where
everyone can run a Generic Kernel Image but a device gets support for
its specific hardware from modules. see
https://lwn.net/Articles/771974/ for more.

we still build the toybox tools, but the system actually has a
libmodprobe that's used as the implementation both for the init
builtin and the command-line modprobe. iirc the other "mod" toys still
have symlinks though.

> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net



More information about the Toybox mailing list