Heads up: bluetoothd on-demand startup

[Bastien Nocera]

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