public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Cc: Kay Sievers <kay.sievers@vrfy.org>,
	Felix Homann <fexpop@onlinehome.de>,
	bluez-devel@lists.sf.net
Subject: Re: [Bluez-devel] bluez udev rules for pcmcia devices
Date: Tue, 25 Jul 2006 19:24:01 +0200	[thread overview]
Message-ID: <1153848241.31069.31.camel@localhost> (raw)
In-Reply-To: <20060725165124.GB14679@esaurito.net>

Hi Filippo,

> I think we should discuss udev rules for bluez (WRT pcmcia cards) as pointed out
> by Marcel while discussing debian bug #378839.
> So far there's a rules file here:
> http://bugs.debian.org/cgi-bin/bugreport.cgi/bluez-pcmcia-support.rules?bug=378839;msg=72;att=1
> and the bluetooth.sh script here:
> http://bugs.debian.org/cgi-bin/bugreport.cgi/bluetooth.sh?bug=378839;msg=72;att=2
> both borrowed in the wild (from SuSE IIRC). See the full bug log for further
> discussion. I basically agree with Marcel because while the bluetooth.sh script
> is invoked /usr might not be mounted yet thus it should not try to execute
> /etc/init.d/bluetooth.

the first thing is that every line for dtl1_cs, bt3c_cs, bluecard_cs,
bt950_cs and btuart_cs must be removed. These are not TTY drivers and
totally useless lines anyway.

Second is that I prefer to call the script "bluetooth_hciattach" or
better maybe "bluetooth_serial", because this is what it is doing. It is
not a generic udev helper for Bluetooth. The job is to attach the serial
port to the hci_uart driver. We can also strip the "/lib/udev/" prefix
and the ".sh" suffix.

Calling /etc/init.d/bluetooth from the script must go away. Either the
support for Bluetooth is enabled or not. The udev helper shouldn't care
about it at all.

Also the line "DEVICE=`echo $DEVNAME|sed -e 's_/dev/__'`" in the script
is not needed at all, because hciattach can handle full device names
without any problems. And in case of some crazy persistent naming rules
it is the safer choice.

>>From a programming perspective, the TYPEID should be moved into
start_serial, because it is its only user.

If this script isn't distributed via bluez-utils, then the script must
check if hciattach is installed. Otherwise you will see errors and this
might not be what users expect.

And we should actually only call hciattach instances using the specified
device. Don't kill something that you didn't start.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

  reply	other threads:[~2006-07-25 17:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-25 16:51 [Bluez-devel] bluez udev rules for pcmcia devices Filippo Giunchedi
2006-07-25 17:24 ` Marcel Holtmann [this message]
2006-07-26  9:49   ` Filippo Giunchedi
2006-07-26 10:07     ` Felix Homann
2006-07-26 14:20     ` 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=1153848241.31069.31.camel@localhost \
    --to=marcel@holtmann.org \
    --cc=bluez-devel@lists.sf.net \
    --cc=bluez-devel@lists.sourceforge.net \
    --cc=fexpop@onlinehome.de \
    --cc=kay.sievers@vrfy.org \
    /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