On Sat, 2010-11-13 at 20:50 +0200, Andrew wrote: > 13.11.2010 12:24, davidMbrooke пишет: > > On Sat, 2010-11-13 at 11:11 +0200, Andrew wrote: > >> 12.11.2010 20:24, davidMbrooke пишет: > >>> I see that we are using "CONFIG_MODPROBE_SMALL" rather than > >>> "CONFIG_MODPROBE" for BusyBox. Is there a good reason for that? Would > >>> switching to CONFIG_MODPROBE be a practical option? > >>> > >>>> From comparing the source code (modprobe.c versus modprobe-small.c) it > >>> seems to me that modprobe.c would give us (more) standard Debian > >>> behaviour... > >>> > >>> dMb > >> As I remembered, standard modprobe requires presence of System.map (file > >> with kernel symbols) which has huge size. But I can mistake. > > Hi Andrew, > > > > Is it fairly easy to check on that? > > > > I will soon be off-line until tomorrow, and I know you wanted a quick > > answer on this, so my thinking is: > > > > - If CONFIG_MODPROBE is a practical option (e.g. no need for > > System.map) then I would prefer to change to that. > > > > - If CONFIG_MODPROBE is *not* a practical option I am OK with > > patching BusyBox - kp convinced me :-) > > > Best way - to look in code, or to assemble bb, copy it somewhere on > running distro, and run in's modprobe.
I finally got chance to try this. I rebuilt everything from scratch (I was due a rebuild anyway) and changed the BusyBox .config to select CONFIG_MODPROBE rather than CONFIG_MODPROBE_SMALL. Everything seems to work fine, and no need for System.map. The differences between the two .configs are: 4c4 < # Sun Oct 31 17:58:13 2010 --- > # Sun Nov 14 18:00:51 2010 473,475c473,475 < CONFIG_MODPROBE_SMALL=y < CONFIG_FEATURE_MODPROBE_SMALL_OPTIONS_ON_CMDLINE=y < CONFIG_FEATURE_MODPROBE_SMALL_CHECK_ALREADY_LOADED=y --- > # CONFIG_MODPROBE_SMALL is not set > # CONFIG_FEATURE_MODPROBE_SMALL_OPTIONS_ON_CMDLINE is not set > # CONFIG_FEATURE_MODPROBE_SMALL_CHECK_ALREADY_LOADED is not set 478,485c478,485 < CONFIG_FEATURE_MODPROBE_SMALL_LOAD_ALIAS_WITH_LONGEST_PREFIX=y < # CONFIG_INSMOD is not set < # CONFIG_RMMOD is not set < # CONFIG_LSMOD is not set < # CONFIG_FEATURE_LSMOD_PRETTY_2_6_OUTPUT is not set < # CONFIG_MODPROBE is not set < # CONFIG_FEATURE_MODPROBE_BLACKLIST is not set < # CONFIG_DEPMOD is not set --- > # CONFIG_FEATURE_MODPROBE_SMALL_LOAD_ALIAS_WITH_LONGEST_PREFIX is not set > CONFIG_INSMOD=y > CONFIG_RMMOD=y > CONFIG_LSMOD=y > CONFIG_FEATURE_LSMOD_PRETTY_2_6_OUTPUT=y > CONFIG_MODPROBE=y > CONFIG_FEATURE_MODPROBE_BLACKLIST=y > CONFIG_DEPMOD=y 497,499c497,499 < # CONFIG_FEATURE_CHECK_TAINTED_MODULE is not set < # CONFIG_FEATURE_MODUTILS_ALIAS is not set < # CONFIG_FEATURE_MODUTILS_SYMBOLS is not set --- > CONFIG_FEATURE_CHECK_TAINTED_MODULE=y > CONFIG_FEATURE_MODUTILS_ALIAS=y > CONFIG_FEATURE_MODUTILS_SYMBOLS=y I didn't realize that these last three "common" options were not set before. They seemed like a good idea when I was answering the config prompts. Perhaps we can leave these as they are. I have not investigated the module options handling but comments in modprobe.c indicate that /etc/modprobe.conf (or /etc/modules.conf) are searched for module option settings, e.g. options tulip2 irq=4 io=0x308 Does that let us do what we need with module options? dMb ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
