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