Re: OT(?) -- Should the net.agent script cause "ifup lo" to be run?

["Adam J. Richter" <adam@yggdrasil.com>]

Miles Lane <miles@megapathdsl.net> 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