public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Bastien Nocera <hadess@hadess.net>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Stefan Seyfried <seife@suse.de>, linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH] Add udev mode to bluetoothd
Date: Fri, 12 Jun 2009 18:58:57 +0100	[thread overview]
Message-ID: <1244829538.11069.2800.camel@cookie.hadess.net> (raw)
In-Reply-To: <1244820498.5536.7.camel@violet>

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

  reply	other threads:[~2009-06-12 17:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-11 17:38 [PATCH] Add udev mode to bluetoothd Bastien Nocera
2009-06-11 17:50 ` Marcel Holtmann
2009-06-12  7:40   ` Stefan Seyfried
2009-06-12  8:28     ` Stefan Seyfried
2009-06-12 17:43       ` Bastien Nocera
2009-06-12  8:40     ` Bastien Nocera
2009-06-12 15:28       ` Marcel Holtmann
2009-06-12 17:58         ` Bastien Nocera [this message]
2009-06-13 19:51           ` Marcel Holtmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1244829538.11069.2800.camel@cookie.hadess.net \
    --to=hadess@hadess.net \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=seife@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox