[Toybox] depmod & modprobe?

[Rob Landley]

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