Proper way to autoload modules (/etc/rc.modules)?

[Kyrre Ness Sjobak]

ons, 06.04.2005 kl. 10.23 skrev Axel Thimm:
> On Wed, Apr 06, 2005 at 12:22:25AM -0700, Pete Zaitcev wrote:
> > On Tue, 5 Apr 2005 12:05:19 +0200 Axel Thimm <Axel.Thimm at ATrpms.net> wrote:
> > 
> > >  Having an init.d only with a modprobe is the wrong design.
> > 
> > What makes you say that? How is it different from having an
> > /etc/modules.d/ivtv?
> 
> It is not a service and get's loaded early enough.
> 
> > I would say that reflexive, knee-jerk reaction "let's add .d" to any
> > problem is a recipe for wrong design which produces
> > redundancies.
> 
> Name one :)
> 
> > Don't forget that it's easy to introduce entities, not so easy to
> > get rid of them.
> 
> So let's make sure this is a sensible one, which IMHO is very much.
>  
> > > And there are other modules that need to be before any init.d scripts,
> > > like capabilities modules whose absence will break named etc.
> > 
> > The named's number is 55. Surely a slot to load capabilities before
> > named can be found.
> 
> That's a kludge and tends to break. Do you really want /etc/init.d to
> get filled with fake services that all start with 00_*?
> 
> > So far I did not see a good reason to keep /etc/rc.modules around
> > in this thread (with a possible exception of pcspkr, because it
> > plugs into HID; but even there a smart kernel patch ought to help).
> 
> Who cares about pcspkr, that's cosmetics. No, a mechanism is needed,
> if you don't like /etc/rc.modules.d suggest something else, but not
> a fake mapping into the services. We could probably map all of
> modprobe.conf into /etc/init.d, too. ;)

What is that "intitializing sound network storage done [ OK ]" before
X11 is loaded do?