On Sunday 22 June 2008 19:36, Vladimir Dronnikov wrote:
> > I don't understand. In which state?
>
> Lines 130, 141, 142 etc. of Config.in in BB modutils. It states that there
> exists bloat.
>
> > Yes, and let's also change options of "find" and "dd", they are
> > so un-Unixy and inconvenient. Our new ones will be shorter to type
> > and parsing code will be smaller (we can reuse getopt32()).
> >
> > Nice idea, eh? Do you see why it could be not such a good idea?
>
> No, no, no! Noone talks of command line options being changed, Denys.
> Changed is the internal representation of data constituting intrinsic module
> dependencies and options.
> > Vladimir, you are not responding to my concern that having incompatible
> > _interface_ of our module tools will hamper adoption of busybox
> > in desktop systems.
>
> Interface _does_ remain compatible. Moreover, more BBification is suggested.
> Loosely bound tools depmod/modprobe/insmod/rmmod is bound tightlier in one
> called modprobe. The rest are just simplest wrappers:
>
> depmod := modprobe
>
> rmmod := modprobe -r
>
> etc.
>
> Since there is no need in explicit depmod (the first call to modprobe will
> generate dependencies if they are missing)
+ // goto modules directory
+ xchdir(CONFIG_DEFAULT_MODULES_DIR);
+ if (uname(&uts) >= 0)
+ chdir(uts.release);
+
+ // prepare module definitions
+ modules_dep = xmalloc_open_read_close(CONFIG_DEFAULT_DEPMOD_FILE, NULL);
+ // no modules.dep? -> create it
It is better to not use "modules.dep" file, it is presumed
to have "standard" format. As I understand your code
generates different one.
+ if (!modules_dep) {
+ // depmod: dump modules definitions
+ int fd = xopen(CONFIG_DEFAULT_DEPMOD_FILE, O_CREAT | O_TRUNC |
O_WRONLY);
What will happen if /lib/modules is read-only
(it is ro on my machine)?
+ recursive_action(CONFIG_DEFAULT_MODULES_DIR,
Is it correct directory? Should it be "." instead?
+ ACTION_RECURSE, /* flags */
+ fileAction, /* file action */
+ NULL, /* dir action */
+ (void *)fd, /* user data */
+ 0 /* depth */
+ );
> all depmod quirks (setting base
> directory, kernel version, etc.) are obsolete.
Too bad depmod is used when I run "make modules_install" when I build new
kernels.
Will it error out now?
> No need to prepare
> dependencies for target system -- no need to depmod.
>
> Again, all the stuff is entirely compiled out if one requires desktop
> compatibility. Having read all this don't you think we can advance on both
> desktop and embedded field if we adopt the way as a simplified modutils
> alternative?
It should be compatible. depmod should behave as expected in
kernel's "make modules_install" step. Even if it doesn't create
modules.dep, it should not fail. Can you make it so?
--
vda
_______________________________________________
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
