On Thu, 2010-11-11 at 19:50 +0100, KP Kirchdoerfer wrote: > Am Donnerstag, 11. November 2010, 19:25:34 schrieb davidMbrooke: > > On Wed, 2010-11-10 at 22:28 +0100, KP Kirchdoerfer wrote: > > > Am Mittwoch, 10. November 2010, 22:14:53 schrieb davidMbrooke: > > > > On Wed, 2010-11-10 at 19:49 +0200, Andrew wrote: > > > > > Hi all. > > > > > I asked in other thread about this, but IMHO question is enough > > > > > important to create separate topic. > > > > > We must decide before beta1, how we will maintain files with module > > > > > options. > > > > > > > > > > One way I described earlier - to rename /etc/modules to different > > > > > name (for ex., /etc/modules.conf), and make /etc/modules/ directory > > > > > for module options. > > > > > Another way is to patch busybox so it will look for options in other > > > > > directory, for ex., /etc/modprobe.d/ > > > > > > > > > > It'll be good if we will make decision in nearest 2-3 days - because > > > > > I really need this feature (for mentioned nf_conntrack module). > > > > > > > > Hi Andrew, > > > > > > > > Personally, I think that patching BusyBox will lead to more confusion > > > > in the long run so I prefer not to do that. > > > > > > > > It seems to me that many modules have changed between the 2.4 and 2.6 > > > > kernels, so anyone hoping for a 3.x -> 4.x upgrade that "just works" > > > > with respect to module loading is going to be disappointed. Adding a > > > > further step to an upgrade to cope with a name change on one file is > > > > not so bad, IMHO. We can cover it in the upgrade documentation. > > > > > > > > I am happy for us to rename /etc/modules if that is the least bad thing > > > > to do. > > > > > > Three men, four opinions - this is the sort of responses, that will not > > > help Andrew :)) > > > > > > For shure an easy upgrade is impossible with such a major change. > > > But go with an unchanged /etc/modules, and a patched bb, won't change > > > anything for current code and users who doesn't want to deal with > > > hwdetect - see Erichs mail yesterday. > > > > > > But why do you think that a bb patch will lead to more confusion? We've > > > had always added patches to bb, and it doesn't lead to confusion. It's a > > > bit more work to build a new bb version, but then it helps the users. > > > > > > I also believe that the decision of busybox developers to use > > > /etc /modules instead /etc/modules.d or /etc/modprobe.d is not the > > > best > > > one they had made. Usually additional config files are stored in > > > directories, which are signalled to the user as with *.d name - so I > > > think a bb patch just moves bb to a widely used approach. > > > > > > kp > > Hi David; > > > My thinking was that the busybox developers have set a "standard" and we > > should stick with that if we can, and also that we if have to change > > then changing now is OK because of so many differences with module > > loading for 4.x > > Understand first part and agree with the second! > > > If you disagree with the busybox "standard" then OK, we can patch it, > > but we should align with some other (better) standard for this exact > > same function. > > /etc/modprobe.d is used at least by Debian and Ubuntu. > > It's IMHO not "better" just "another one". > > My main point is that patching bb instead of renaming /etc/modules is less > intrusive for LEAF. Agreed... at least in terms of the transition from 3.x to 4.x > > kp
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 ------------------------------------------------------------------------------ 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