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

Reply via email to