As discussed on IRC.
Still needed:
- patch to wait for the bus to startup in udev mode
- udev rules
- unleash for testing
Cheers
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
On Fri, 2009-06-12 at 17:28 +0200, Marcel Holtmann wrote:
> Hi Bastien,
>
> > > >> As discussed on IRC.
> > > >>
> > > >> Still needed:
> > > >> - patch to wait for the bus to startup in udev mode
> > >
> > > Should we really do that? (What if the bus never appears?, how long should we
> > > wait?)
> > > The alternative (not overwhelmingly nice, I admit) would be to record
> > > somewhere in the system that bluetoothd tried to start but could not due to
> > > the missing bus and then start it "manually" by an init script that is
> > > guaranteed to run after DBus is started.
> >
> > 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.
Cheers
On Fri, 2009-06-12 at 10:28 +0200, Stefan Seyfried wrote:
> Stefan Seyfried wrote:
>
> > I had patches for waiting for the bus long time ago and can dig them out if
> > wanted.
>
> Actually I quickly dug them out and adapted them to the current code.
>
> I arbitrarily chose to stop waiting after 5 minutes. This timeout is certainly
> a topic that might need to be discussed.
This patch won't work as part of the udev mode, as we don't daemonise
until we have a D-Bus connection. That would make udev hang for 5
minutes waiting for the helper to come back.
Hi Bastien,
> > >> As discussed on IRC.
> > >>
> > >> Still needed:
> > >> - patch to wait for the bus to startup in udev mode
> >
> > Should we really do that? (What if the bus never appears?, how long should we
> > wait?)
> > The alternative (not overwhelmingly nice, I admit) would be to record
> > somewhere in the system that bluetoothd tried to start but could not due to
> > the missing bus and then start it "manually" by an init script that is
> > guaranteed to run after DBus is started.
>
> 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?
Regards
Marcel
On Fri, 2009-06-12 at 09:40 +0200, Stefan Seyfried wrote:
> Marcel Holtmann wrote:
> > Hi Bastien,
> >
> >> As discussed on IRC.
> >>
> >> Still needed:
> >> - patch to wait for the bus to startup in udev mode
>
> Should we really do that? (What if the bus never appears?, how long should we
> wait?)
> The alternative (not overwhelmingly nice, I admit) would be to record
> somewhere in the system that bluetoothd tried to start but could not due to
> the missing bus and then start it "manually" by an init script that is
> guaranteed to run after DBus is started.
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.
> I had patches for waiting for the bus long time ago and can dig them out if
> wanted.
Sure, as long as it's not bluez 3.x stuff :)
Stefan Seyfried wrote:
> I had patches for waiting for the bus long time ago and can dig them out if
> wanted.
Actually I quickly dug them out and adapted them to the current code.
I arbitrarily chose to stop waiting after 5 minutes. This timeout is certainly
a topic that might need to be discussed.
Best regards,
Stefan
--
Stefan Seyfried
R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
Marcel Holtmann wrote:
> Hi Bastien,
>
>> As discussed on IRC.
>>
>> Still needed:
>> - patch to wait for the bus to startup in udev mode
Should we really do that? (What if the bus never appears?, how long should we
wait?)
The alternative (not overwhelmingly nice, I admit) would be to record
somewhere in the system that bluetoothd tried to start but could not due to
the missing bus and then start it "manually" by an init script that is
guaranteed to run after DBus is started.
I had patches for waiting for the bus long time ago and can dig them out if
wanted.
Best regards,
Stefan
--
Stefan Seyfried
R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
Hi Bastien,
> As discussed on IRC.
>
> Still needed:
> - patch to wait for the bus to startup in udev mode
> - udev rules
> - unleash for testing
patch has been applied. Thanks.
Regards
Marcel