On Fri, 2009-06-12 at 14:11 -0400, Kyle McMartin wrote: > On Fri, Jun 12, 2009 at 07:05:39PM +0100, Bastien Nocera wrote: > > I've added a patch to bluetoothd in F-12 to support being started via > > udev, on-demand. bluetoothd will now only start up when you have a > > Bluetooth adapter plugged, and will exit 30 seconds after the last one > > went away. > > > > The only purpose of the bluetooth initscript is now to switch HID proxy > > adapters into Bluetooth mode (on Macs, and some Logitech and Dell > > keyboard/mouse combos). That'll probably go away as well, and into udev. > > > > File bugs against bluez if you encounter any problems with bluetoothd > > being in the wrong state (ie. started with no Bluetooth hardware, and > > not running when you have Bluetooth hardware). > > > > I've been hoping to find some time to do a big review of system startup > for F-12, but haven't as yet found the time... > > How does this actually work? At what stage of boot does udev attempt to > start bluetoothd? Best explanation is here: http://thread.gmane.org/gmane.linux.bluez.kernel/2474 Every time there's an add action for a Bluetooth device, udev will run "bluetoothd --udev". bluetoothd will fail with an error if D-Bus isn't started (on bootup), and the udev coldplug (done in udev-post) will run the rule again. bluetoothd will silently fail when it's already running. bluetoothd will exit itself after 30 seconds when no adapters are present. There's a potential race if the udev add event happens in between the time the time the running bluetoothd reliquinshes its D-Bus service, and the new one starts up. I don't think it's likely to cause problems in real life, unless the machine is so heavily bogged down that the time between the timeout kicking in and the close of the D-Bus service is long. But then again, udev might be bogged down as well. > One of my ideas(I guess?) for F-12 is to filter modules loaded at boot > by udev, and defer things that aren't needed for startup until either > idle, or they are needed. (Why do we need sound modules loaded before we > mount root rw? :) Would that really make bootup faster, or you'd get to a rw filesystem faster? > I've got a couple hacks from LPC last year I need to > polish and submit for cups to make it somewhat more sensible... A quick scan tells me that a number of services should be disabled by default, and: 1) enabled explicitely by the user when they switch on the "network" service (iscsi, ntpd, rpcbind, etc.), and disable NetworkManager (and be enabled as required when NetworkManager gets a network interface up) 2) the livesys script should remove itself (and livesys-late) from the initscripts if it is that it's been installed 3) smolt should probably be running from cron? > Pardon my curiosity, this is a big step towards better boot up. Thanks > for doing this! Cheers -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
