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