Heads up: bluetoothd on-demand startup

[Bastien Nocera]

Heya,

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

Cheers

[Kyle McMartin]

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?

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? :) I've got a couple hacks from LPC last year I need to
polish and submit for cups to make it somewhat more sensible...

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

cheers, Kyle

[drago01]

On Fri, Jun 12, 2009 at 8:11 PM, Kyle McMartin<kyle(a)mcmartin.ca> 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?
>
>  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? :) I've got a couple hacks from LPC last year I need to
>  polish and submit for cups to make it somewhat more sensible...
>
>  Pardon my curiosity, this is a big step towards better boot up. Thanks
>  for doing this!
>
>  cheers, Kyle 
https://bugzilla.redhat.com/show_bug.cgi?id=484345

[Bastien Nocera]

On Fri, 2009-06-12 at 20:20 +0200, drago01 wrote:
>  On Fri, Jun 12, 2009 at 8:11 PM, Kyle
> McMartin<kyle(a)mcmartin.ca> 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?
>  >
>  > 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? :) I've got a couple hacks from LPC last year I need to
>  > polish and submit for cups to make it somewhat more sensible...
>  >
>  > Pardon my curiosity, this is a big step towards better boot up. Thanks
>  > for doing this!
>  >
>  > cheers, Kyle
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=484345 
Nope, that was the code that was in F-12 up until now, which I removed,
and replace with a better way. There's no initscripts needed anymore.

Cheers

[drago01]

On Fri, Jun 12, 2009 at 8:27 PM, Bastien Nocera<bnocera(a)redhat.com> wrote:
>  On Fri, 2009-06-12 at 20:20 +0200, drago01 wrote:
> > On Fri, Jun 12, 2009 at 8:11 PM, Kyle McMartin<kyle(a)mcmartin.ca> 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?
> > >
> > > 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? :) I've got a couple hacks from LPC last year I need to
> > > polish and submit for cups to make it somewhat more sensible...
> > >
> > > Pardon my curiosity, this is a big step towards better boot up. Thanks
> > > for doing this!
> > >
> > > cheers, Kyle
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=484345
>
>  Nope, that was the code that was in F-12 up until now, which I removed,
>  and replace with a better way. There's no initscripts needed anymore. 
Oh, nice.

[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

[Colin Walters]

On Fri, Jun 12, 2009 at 2:26 PM, Bastien Nocera<bnocera(a)redhat.com> wrote:
>  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. 
We should support this I think.  I've added a bug here:

https://bugs.freedesktop.org/show_bug.cgi?id=22258

[Bastien Nocera]

On Fri, 2009-06-12 at 14:39 -0400, Colin Walters wrote:
>  On Fri, Jun 12, 2009 at 2:26 PM, Bastien
> Nocera<bnocera(a)redhat.com> wrote:
>  >
>  > 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.
>  
>  We should support this I think.  I've added a bug here:
>  
>  https://bugs.freedesktop.org/show_bug.cgi?id=22258 
We don't use D-Bus for that in-flight message.

The message is in-flight between the kernel and bluetoothd via netlink.

   1. running bluetoothd           2. adapter insertion

- last bt adapter gets removed
- timeout kicks in
       30 sec...
- we start processing shutdown
                                   - udev gets event from the kernel
                                   - udev rule is processed
                                   - bluetoothd is run with --udev
                                   - bluetoothd exits because the
                                     service is already running
- relinquish the D-Bus service
- bluetoothd exits

Something like that.

[Lennart Poettering]

On Fri, 12.06.09 19:26, Bastien Nocera (bnocera(a)redhat.com) wrote:

>  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. 
This could be fixed by first releasing the service name synchronously,
then processing all queued requests and only then closing/exiting.

Hmm, will bluetoothd also be started via bus activation? If so, it
wuld probably make sense to issue a StartByName D-Bus request from the
udev rule and let dbus handle all the ordering/synchronization issues
with starting up bluetoothd.

I know at least one application (PA) that wouldn't reconnect to coming
and going bluetoothd's, that's why I am asking.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Bastien Nocera]

On Fri, 2009-06-12 at 20:44 +0200, Lennart Poettering wrote:
>  On Fri, 12.06.09 19:26, Bastien Nocera (bnocera(a)redhat.com) wrote:
>  
>  > 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.
>  
>  This could be fixed by first releasing the service name synchronously,
>  then processing all queued requests and only then closing/exiting.
>  
>  Hmm, will bluetoothd also be started via bus activation? If so, it
>  wuld probably make sense to issue a StartByName D-Bus request from the
>  udev rule and let dbus handle all the ordering/synchronization issues
>  with starting up bluetoothd. 
No, there's no service activation support. Would it be useful?

>  I know at least one application (PA) that wouldn't reconnect to
> coming
>  and going bluetoothd's, that's why I am asking. 
Which is why we're doing it early in F-12. At least obex-data-server is
broken as well.

[Lennart Poettering]

On Fri, 12.06.09 20:10, Bastien Nocera (bnocera(a)redhat.com) wrote:

>  > This could be fixed by first releasing the service name
> synchronously,
>  > then processing all queued requests and only then closing/exiting.
>  > 
>  > Hmm, will bluetoothd also be started via bus activation? If so, it
>  > wuld probably make sense to issue a StartByName D-Bus request from the
>  > udev rule and let dbus handle all the ordering/synchronization issues
>  > with starting up bluetoothd.
>  
>  No, there's no service activation support. Would it be useful? 
I think it would. Seems to me as if some of the BT functionality
(org.bluez.Manager, ...) might be useful even without having hw
plugged in.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Bastien Nocera]

On Fri, 2009-06-12 at 21:52 +0200, Lennart Poettering wrote:
>  On Fri, 12.06.09 20:10, Bastien Nocera (bnocera(a)redhat.com) wrote:
>  
>  > > This could be fixed by first releasing the service name synchronously,
>  > > then processing all queued requests and only then closing/exiting.
>  > > 
>  > > Hmm, will bluetoothd also be started via bus activation? If so, it
>  > > wuld probably make sense to issue a StartByName D-Bus request from the
>  > > udev rule and let dbus handle all the ordering/synchronization issues
>  > > with starting up bluetoothd.
>  > 
>  > No, there's no service activation support. Would it be useful?
>  
>  I think it would. Seems to me as if some of the BT functionality
>  (org.bluez.Manager, ...) might be useful even without having hw
>  plugged in. 
All the API in doc/manager-api.txt shows that org.bluez.Manager's sole
purpose is to tell you about available Adapters, and enumerate them.
It's useless without an adapter plugged in.

[Lennart Poettering]

On Fri, 12.06.09 22:17, Bastien Nocera (bnocera(a)redhat.com) wrote:

>  > > No, there's no service activation support. Would it be
> useful?
>  > 
>  > I think it would. Seems to me as if some of the BT functionality
>  > (org.bluez.Manager, ...) might be useful even without having hw
>  > plugged in.
>  
>  All the API in doc/manager-api.txt shows that org.bluez.Manager's sole
>  purpose is to tell you about available Adapters, and enumerate them.
>  It's useless without an adapter plugged in. 
Hmm, but what about the "any" object which provides org.bluez.Service?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Bastien Nocera]

On Fri, 2009-06-12 at 23:58 +0200, Lennart Poettering wrote:
>  On Fri, 12.06.09 22:17, Bastien Nocera (bnocera(a)redhat.com) wrote:
>  
>  > > > No, there's no service activation support. Would it be useful?
>  > > 
>  > > I think it would. Seems to me as if some of the BT functionality
>  > > (org.bluez.Manager, ...) might be useful even without having hw
>  > > plugged in.
>  > 
>  > All the API in doc/manager-api.txt shows that org.bluez.Manager's sole
>  > purpose is to tell you about available Adapters, and enumerate them.
>  > It's useless without an adapter plugged in.
>  
>  Hmm, but what about the "any" object which provides org.bluez.Service? 
What would you use that for? Check for a particular service (such as the
audiosink, etc.) being available? Do you do something special when that
happens? Wouldn't the devices just be invisible to PA in that case?

If we wanted to add support for dbus activation, we'd also need to
implement a way to close ourselves if no dbus connection were made in a
certain amount of time.

[Lennart Poettering]

On Fri, 12.06.09 23:27, Bastien Nocera (bnocera(a)redhat.com) wrote:

>  
>  On Fri, 2009-06-12 at 23:58 +0200, Lennart Poettering wrote:
>  > On Fri, 12.06.09 22:17, Bastien Nocera (bnocera(a)redhat.com) wrote:
>  > 
>  > > > > No, there's no service activation support. Would it be useful?
>  > > > 
>  > > > I think it would. Seems to me as if some of the BT functionality
>  > > > (org.bluez.Manager, ...) might be useful even without having hw
>  > > > plugged in.
>  > > 
>  > > All the API in doc/manager-api.txt shows that org.bluez.Manager's sole
>  > > purpose is to tell you about available Adapters, and enumerate them.
>  > > It's useless without an adapter plugged in.
>  > 
>  > Hmm, but what about the "any" object which provides org.bluez.Service?
>  
>  What would you use that for? Check for a particular service (such as the
>  audiosink, etc.) being available? Do you do something special when that
>  happens? Wouldn't the devices just be invisible to PA in that case? 
I was more thinking of installing some SDP data or so. Not that I'd
have any particular need for that right now, but that's what the API
is for afaiu.

>  If we wanted to add support for dbus activation, we'd also need
> to
>  implement a way to close ourselves if no dbus connection were made in a
>  certain amount of time. 
Yes, you'd have to count both clients and BT adapters, then.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Robert Nichols]

Bastien Nocera wrote:
>  On Fri, 2009-06-12 at 20:44 +0200, Lennart Poettering wrote:
> > Hmm, will bluetoothd also be started via bus activation? If so, it
> > wuld probably make sense to issue a StartByName D-Bus request from the
> > udev rule and let dbus handle all the ordering/synchronization issues
> > with starting up bluetoothd.
>  
>  No, there's no service activation support. Would it be useful? 
It would be nice to start bluetoothd automatically when I plug in
my USB Bluetooth adapter (IOgear GBU421, 0a5c:2101 Broadcom Corp.).

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

[drago01]

On Fri, Jun 12, 2009 at 11:15 PM, Robert
Nichols<rnicholsNOSPAM(a)comcast.net> wrote:
>  Bastien Nocera wrote:
> >
> > On Fri, 2009-06-12 at 20:44 +0200, Lennart Poettering wrote:
> >>
> >> Hmm, will bluetoothd also be started via bus activation? If so, it
> >> wuld probably make sense to issue a StartByName D-Bus request from the
> >> udev rule and let dbus handle all the ordering/synchronization issues
> >> with starting up bluetoothd.
> >
> > No, there's no service activation support. Would it be useful?
>
>  It would be nice to start bluetoothd automatically when I plug in
>  my USB Bluetooth adapter (IOgear GBU421, 0a5c:2101 Broadcom Corp.). 
err... thats what the whole thing is about ;)

[Kyle McMartin]

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.
>   
*nod*

>  > 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...
http://fedorapeople.org/~kyle/minerva-f11-bootchart-2009-05-31.pdf
(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

[Rahul Sundaram]

On 06/12/2009 11:35 PM, Bastien Nocera wrote:
>  Heya,
>  
>  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. 
Can you add these details to

https://fedoraproject.org/wiki/Fedora_12_Beta_release_notes

Rahul

[Bastien Nocera]

On Fri, 2009-06-12 at 23:59 +0530, Rahul Sundaram wrote:
>  On 06/12/2009 11:35 PM, Bastien Nocera wrote:
>  > Heya,
>  > 
>  > 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.
>  
>  Can you add these details to
>  
>  https://fedoraproject.org/wiki/Fedora_12_Beta_release_notes 
Will do.

Cheers

[Rahul Sundaram]

On 06/13/2009 12:43 AM, Bastien Nocera wrote:
>  On Fri, 2009-06-12 at 23:59 +0530, Rahul Sundaram wrote:
> > On 06/12/2009 11:35 PM, Bastien Nocera wrote:
> >> Heya,
> >>
> >> 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.
> >
> > Can you add these details to
> >
> > https://fedoraproject.org/wiki/Fedora_12_Beta_release_notes
>  
>  Will do. 
Are you still planning on doing this? Do you need help?

Rahul