THe discussion have to happen on the mailing list! Please CC [EMAIL PROTECTED]
2008/7/10 Vladimir Dronnikov <[EMAIL PROTECTED]>: >>> I liked the idea of not needing depfile at all and still > >>> being reasonably fast. And it's actually YOUR idea - >>> I based my work on your depfile-less patch. > > :) > > The only catch is system startup. If 5 more seconds is not of big concern, > let us get rid of modules.dep.bb. Again, there exist much more time > consuming operations at startup so the delay is not so dramatic! There are people whose target is 1 second boot, total time. Don't have to match that, but keep it in mind as a yardstick. >>> I am planning to make depfile generation optional... > > This would also solve the problem of modutils to be fool-proof. I know > people who constantly try to edit something (like depfile :). > >>> But first I want to be sure that full-blown (all options on) version >>> works for desktop users. > > Understood. Agreed. > Just drank a cup of tee and another idea came. If we advance your approach > of lazy scanning only needed modules further we could get rid of the > problems at all. When we have to snoop into module file we should make > _symlinks_ to the module file which are named after all the aliases and > symbols it contains. That way the next time when a symbol:pci:foo:bar is > queried we have direct answer: use this particular module! We already have > to use fnmatch(), why not to use filesystem means directly? The only > drawback is again RO filesystem, but a system has to have some RW > filesystem, be it tmpfs or the other (/etc, e.g), right? Crazy idea. Might be fun to try. I propose to put links into aliases/ subdir. RO filesystem got to live without depmod info then. User's choice. The drawback is the size. With links, you can't use "modules.dep.bb.bz2" trick. -- vda _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
