[Toybox] depmod & modprobe?

[scsijon]

On 06/03/20 05:23, Rob Landley 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. :)
> 
many thanks

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

I have no ideas, maybe as long as it can use those 'specific names' and 
get back the results it expects in the correct (as far as it's 
concerned) format, it's happy

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

sounds what kmod does, however it expects at least modprobe and depmod 
to be individual files for me, not links which errors out.

> 
>>>> 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 can try, give me something to run and I can give feedback at least

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

dam, can't find that link listing the desktop problems at present, will 
look it out later.

There's a number of doc's on this however, i'll look more url's out for 
you if you 'need' them, however this will give an idea of some of the 
mdev problems.
https://github.com/slashbeast/mdev-like-a-boss
https://forum.artixlinux.org/index.php/topic,530.0.html
https://serverfault.com/questions/303085/what-is-mdev-and-how-to-dev-nodes-get-created-in-linux

Gentoo use mdev, so I expect they will have plenty on it's problems. 
(167 in gentoo and most seem to relate to a couple of missing kernel 
settings, hm not your problem).

And funtoo also has something called smdev that may be of use,
https://forums.funtoo.org/topic/193-smdev-guide-eudev-alternative/
https://www.funtoo.org/Package:Smdev
https://git.suckless.org/smdev/

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

Sorry, I don't know, we don't use systemd anywhere for puppylinux or 
easyos, never did and don't want too!

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

Maybe 'someone' else can answer for android