Hi Bastien, > > > Under normal conditions, we'd exit(1) if started and the bus isn't > > > available, and udev would pick that up, marking our job as failed, and > > > relaunching us later in the boot process, under coldplug. > > > > > > Marcel didn't like the idea though. > > > > so how does udev handle this exactly. We try bluetoothd and it fails, > > then it tries again later? What time exactly? How often? Does this > > affect the fast-boot effort? > > It will try to start up bluetooth as soon as it sees the device on > startup. bluetoothd will fail to start, as D-Bus isn't started, with an > exit code of 1. > > udev notes the failure, and saves the rules to /dev/.udev/*. > > The initscripts carry on, filesystems are mounted rw, D-Bus is started, > then a udev "coldplug" is started (still part of the initscripts), and > bluetoothd is started as expected. > > I built some test packages yesterday, and Petr tested those, and it > seems to work as expected. > > If you fancy trying out on an F-12 system (the SRPM can be re-used on > F-11, just remove the libgudev-devel BuildRequires line): > http://koji.fedoraproject.org/koji/buildinfo?buildID=105952 > > So as far as I'm concerned, the only thing missing is getting the rules > into bluez. > > Marcel, do you want the udev rules installed by default? The cost would > be an attempted run at bluetoothd on each adapter insertion, but it > would still work as expected if bluetoothd was started from an > initscript. I have no problem triggering bluetoothd from udev every time we add a new adapter. And unless we try it, we never know. I am a little bit concerned about the boot time implications of this. Send me a patch with the rules installation and lets make it default. We see how far we get. I do hate init scripts anyway and if they get too complex it costs us actually more time at boot than just starting the daemon. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
