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@xxxxxxxxxx> 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. ;) -- Axel.Thimm at ATrpms.net
Attachment:
pgprMr3syMdO7.pgp
Description: PGP signature
