Ответ: MODPROBE: next generation

[Vladimir Dronnikov]

Hello!

1. Noone wants to bury existing modprobe. I mean a new format for
intermediate data for an utility which will provide the same
functionality but is planned to be smaller, faster and cleaner. Have
you ever edited modules.dep or modules.symbols files manually? Guess
no. And they are the vast majority of (potentially invariant) data
which we have to parse expensively on every module operation. Why not
to try to advance? Or, as they say, "don't touch a sewing tube unless
it leaks"?!

2. BB depmod right now generates (having FEATURE_ALIAS defined, my
case) modules.dep which can not be parsed correctly with BB modprobe.
This is modprobe's issue. Since modprobe's maintaner is now offline
the updates are blocked. How people who shifted from production to BB
modutils (my case again) are supposed to cope this lockout?

3. What's wrong with BB sendmail? Please do request for feature if it
does not fit your needs.

Regards,
--
Vladimir


2008/6/18, Natanael Copa <natanael.copa at gmail.com>:
> On Tue, 2008-06-17 at 10:24 -0700, dronnikov at gmail.com wrote:
>
>> I suggest to invent for BB a custom modules.dep format which bites all
>> above issues.
>
> ...
>
>> Comments?
>
> Please no.
>
> My alpine linux distro is based on uclibc/busybox. If hte busybox
> utility is not good enough for user, then it is possible to install the
> "real" utility that just overrides the busybox version.
>
> This requires that they behave similar. Otherwise scripts and things
> tend to break. (so far its only the sendmail applet that causes problems
> so i had to turn it off)
>
> So, please, continue make busybox compatible with POSIX/GNU standards.
>
> -nc
>
>
>
>