[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Heads up: bluetoothd on-demand startup

On Fri, Jun 12, 2009 at 07:26:34PM +0100, Bastien Nocera wrote:
> > 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.

Ok, that's more or less what I expected.

> 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?

Almost certainly, but it's in the noise compared to deferred service
initialization... I have numbers from my LPC talk last year, but I'd
have to dig to find them.

> >  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)

Yeah, a lot of these are 'interesting' cases though. For instance, why
do we need iscsid always, or nfsd if we have no exports configured, and
no fstab mounts... it could otherwise be on-demand.

Even so, we're doing really well on F-11...
(dell mini 9 with the stock crud ssd. disk seeks kill kittens.)

> 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?

I definitely agree.

> > Pardon my curiosity, this is a big step towards better boot up. Thanks
> > for doing this!
> Cheers

cheers, Kyle

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]