public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Cris <ml133@netpole.com.br>
To: bluez-devel@lists.sourceforge.net
Subject: [Bluez-devel] suggestion for device control
Date: Wed, 6 Dec 2006 11:16:17 -0200	[thread overview]
Message-ID: <20061206111617.d8f16a0c.ml133@netpole.com.br> (raw)

Hi developers,

I'm not a kernel developer, but have a suggestion, which could benefit
a fair amount of the user comunity.

Unfortunately, BlueZ doesn't do always what a particular application
needs, or it does it in a version of a kernel which is just not
available to a particular device. Here is a suggestion which should be
very simple to implement and could provide some relieve:

Would it be possible to have one more socket option, an exclusive
flag, which would allow a programmer to tell the kernel, that this
application will take care of everything itself for the device the
socket is bound to, and that the kernel should just pass the HCI
packets to and from the controller? If this flag was not set,
everything would be as it is now, otherwise, an application could do
any non-standard operation with this device, without having to worry
about interferences. A user could have at the same time one device for
really strange stuff, but another using say an rfcomm device file with
full kernel support.

According to a message in bluez-user, recently a user was in trouble
because he isn't able to update the kernel of his devices to the
latest version. This flag wouldn't help him today, but once it was
available to his kernels, he might get a choice to work around his
problem. As soon as anything non-standard needs to be done, this could
be the only possible solution. Anyway, I don't think, that I'm alone
here. Also, this option would fit well to linux philosophy where there
is not one single windows wishing to control everything
inconditionally.

Thanks,

-- 
Cris

-------------------------------------------------------------------------
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-12-06 13:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-06 13:16 Cris [this message]
2006-12-06 13:39 ` [Bluez-devel] suggestion for device control Marcel Holtmann
2006-12-06 15:17   ` Cris
2006-12-06 15:28     ` Marcel Holtmann
2006-12-06 18:49       ` Cris
2006-12-08 10:16         ` Marcel Holtmann
2006-12-08 11:24           ` Cris

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=20061206111617.d8f16a0c.ml133@netpole.com.br \
    --to=ml133@netpole.com.br \
    --cc=bluez-devel@lists.sourceforge.net \
    /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