While I'm not that aware of various options, I think a few modules are mandatory or have to go with some packages. E.g. ipsec.o with ipsec(509).lrp, bridge.o with bridge.lrp, netfilter with tc.lrp etc. I was looking at this. In addition, 90-95% of the users would use a common combination. Dial up connections use PPP over serial ports etc. Such popular combinations can also be packaged to gether.
Mohan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeff Newmiller Sent: Wednesday, February 19, 2003 12:27 AM To: Matt Schalit Cc: [EMAIL PROTECTED] Subject: Re: [leaf-user] Update: Short term LEAF project goals On Tue, 18 Feb 2003, Matt Schalit wrote: > > > S Mohan wrote: > > I'd also suggest a change in lrp packaging by which the modules > > required for a package to run is bundled with the lrp. Installing > > the lrp will also insmod the module automatically. A depmod kind of > > facility will make it easy to use/ configure LEAF. > > > Give me an example please of a package that requires > you to go out and find a .o module you need. ppp.lrp. The problem with incorporating module dependencies into packages is that modules are supposed to present a standard "application programming interface" that decouples the application from the hardware. PPP can in fact be run over ethernet, or over standard serial ports, or over special multi-port serial interfaces. Even if you put something in the packaging system that can recognize the absence of a minimum functionality (some type of point to point communication channel), you will still have confusion where the application calls for multiple channel types used in different ways (PPPoE into a serial control channel for an embedded device, for example). I think that in most cases coupling the base user-level package with an application-specific set of kernel modules makes more sense than integrating the two. If you really want idiot-level integration, then fall back on application-specific "floppy image"-style delivery. Bering's documentation is much more effective in the general case than trying to integrate into packages items that don't belong together in all cases. ------------------------------------------------------------------------ --- Jeff Newmiller The ..... ..... Go Live... DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/Batteries O.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k ------------------------------------------------------------------------ --- ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
