[Toybox] depmod & modprobe?

[scsijon]

?and poked again (please), as i can't see anything in 0.83 's status page.

many thanks
scsijon

On 6/3/20 5:23 am, 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. :)
> 
>>> 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...
>