From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Adam J. Richter" Date: Sun, 25 Feb 2001 10:03:44 +0000 Subject: Re: OT(?) -- Should the net.agent script cause "ifup lo" to be run? Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Miles Lane writes: >I am wondering how much of the work that is >currently handled by init scripts like >/etc/rc.d/init.d/network ought to migrate into >the hotplug scripts. If the answer is "almost >none," then how should running of "ifup lo" >get triggered when "ifup ethN" is getting run >from /etc/hotplug/net.agent? I ask because >I have been experimenting with relying more >on the /etc/rc.d/init/hotplug init script to >get my PCI, net and USB device drivers loaded >and the devices configured. To this end, I >disabled /etc/rc.d/init/network. The result >is that booting my system worked great, except >/dev/lo wasn't enabled. For some reason, mozilla >doesn't finish initializing if /dev/lo isn't >activated. I would like to see systems in the future that are much more usage driven than the ones of today. For example, I would like to see /etc/fstab handled by some future variant of autofs (not sure if autofs4 would do be enough) and, on systems that do not want to run inetd, I could image the ethernet card being fully powered on and DHCP'ed or otherwise configured only as a result of something on the system trying to send a packet on the network (detected by a facility like diald, which you could try if you want to go that extreme with the "lo" interface). Likewise, getty and xdm would be spawned only as virtual consoles, frame buffers, keyboards and mice were detected (per a policy controlled by /etc/devfsd.conf). Other things which are "configured" today would adjust automatically to accomodate usage: sendmail, httpd, mountd and nfsd would be spawned by inetd in response to requests and these daemons would stick around to handle other requests in case of high load, in the cases of sendmail and httpd, spawning helper children up to some limit if required by the load, but they would eventually exit after a few minutes of inactivity. On such a system, the boot process proper could be very fast. If you wanted to boot your system to edit a few files on your root IDE hard disk, it might never get around to spinning up your your second SCSI hard disk or even loading the driver for the scsi controller. It might not even bother dhcp'ing your network interface. On the other hand, you might want your system to configure everything, at least in the background, just to reduce the pauses the first time you were to use each device. It would depend on how much you cared about kernel footprint and power consumption. Just to illustrate, here is a rough example of the boot process that I have in mind for a system in the future (parts of this are not accurate today): mount /dev # FIXME: Will fsck or autofs need /proc to be manually mounted? # fsck is very fast, because future systems will # run GFS or some other journaling or log based file system. rootdev=$(get_root_device) if ! fsck -p $rootdev ; then exec < /dev/console > /dev/console 2>&1 echo "fsck of root device ($rootdev) failed!" if ! fsck -r $rootdev ; then echo "System will reboot when you exit this shell." sh fi echo "Rebooting." reboot fi autofs -fstab /etc/fstab devfsd /dev enable_hotplugging modprobe isa-pnp modprobe nubus modprobe sbus modprobe pci # Someday "pci" will be a separate module to make the standard # kernel binary's footprint smaller on older non-PCI machines, # and it might not be loaded by the initial ramdisk if the boot # device is on, say, the ISA bus. # Imagine that in the future we have nice consistent names # for busses: for slot in /proc/bus/*/[0-9]*/[0-9]* ; do hotplug $slot # The hotplug scripts will probably only call modprobe # for the devices that we actively want to "listen" to, # like removable media drives and interfaces to other # pluggable busses like USB, FireWire, SCSI, and IDE. # Probably everything else could be triggered by usage, # although you might want to preload them anyhow just # to avoid pauses the first time you access things. # Note that these "listener" kernel modules ought to # have some kind of facility to tell "modprobe -r" not # to automatically remove them even if they've been unused # for a while. done # The following two lines would actually be done by /etc/inittab # or some more exotic runlevel-based system: cron inetd Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104 adam@yggdrasil.com \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel