All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcello Cinque <macinque@unina.it>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Fwd:  hci connect and switch role modifications
Date: Mon, 31 Jul 2006 15:01:33 +0200	[thread overview]
Message-ID: <44CDFF2D.9060003@unina.it> (raw)
In-Reply-To: <1150540477.17539.31.camel@aeonflux.holtmann.net>

[-- Attachment #1: Type: text/plain, Size: 3687 bytes --]

Hi Marcel,

as you asked, i'll send you the modifications separately.

This is the first.
Basically, we added a  mechanism that may use to prevent some errors 
from occurring (error masking mechanism) when performing a 
hci_create_connection. The mechanism is part of the results of our 
research on bluetooth networks. Perhaps the same strategies  can  be  
generalized and applied  on several parts of the code in order to 
improve the overall robustness of the BlueZ stack.
Specifically we added a function to the hci.c file (and related 
hci_lib.h) which name is hci_create_connection_timed.
This function first creates a connection and then checks whether the 
handle is valid (>0) until a given timeout expires. The timeout is 
specified as an additional parameter, in milliseconds. We created this 
function because, while working with bluetooth, we noticed that to get a 
valid handle over a connection may take some time, even after that the 
hci_create_connection function return, due to the asynchronous nature of 
the connection creation process. This could result in a error when 
subsequent calls are performed over the connection with a handle that is 
still not valid (e.g. a bnep create connection call over an already 
created l2cap connection, or a switch role command). This function 
avoids this problem because it returns with no errors only if the 
created connection has a valid handle.
It is worth noting that the function returns a "timer expired (ETIME)" 
error even when the connection is created. This happens when the timeout 
expires but the connection still has a not valid handle. However, the 
handle could become valid after the function exits.

We preferred to provide a new function rather than modifying the 
original ones. This way the user can choose to use the function that 
better suites his requirements.

In order to test and use the new functionalities, we also slightly 
modified the hcitool.c program, so as to add an optional parameter 
"--timeout" to the "cc" command. If the parameter is specified the new 
functions are called, otherwise the original functions are used.

Let me know if this can be of interest, in which case I'll send you also 
the second modification, on the switch role command.

Best regards,
Marcello Cinque
Fabio Cornevilli
Mobilab Research Group - www.mobilab.unina.it



Marcel Holtmann wrote:

>Hi Marcello,
>
>  
>
>>in february I sent you the email in the following, about some proposed 
>>modifications in the HCI connect and switch role APIs. At that time, I also attached 
>>you the unified diff files, which I'm attaching also now.
>>Anyway, I didn't receive any reply. Do you think these modifications are 
>>likely to be integrated in next releases?
>>    
>>
>
>I might have missed that. Sorry, but this can happen from time to time.
>
>If you propose multiple changes then please split them and post them
>separately if possible. This makes it easier for me to review them and
>then integrate them.
>
>Regards
>
>Marcel
>
>
>
>
>_______________________________________________
>Bluez-devel mailing list
>Bluez-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>  
>


-- 
Marcello Cinque, PhD Candidate
Dipartimento di Informatica e Sistemistica
Università di Napoli Federico II
Via Claudio, 21 - 80125 Napoli, Italy
Ph:  +39-081-7683874
Fax: +39-081-7683816
Web: wpage.unina.it/macinque
The MobiLab Group - www.mobilab.unina.it 


-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.


[-- Attachment #2: bluez_patches.tar.gz --]
[-- Type: application/gzip, Size: 1730 bytes --]

[-- Attachment #3: Type: text/plain, Size: 348 bytes --]

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

[-- Attachment #4: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

      reply	other threads:[~2006-07-31 13:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-12 16:49 [Bluez-devel] Fwd: hci connect and switch role modifications Marcello Cinque
2006-06-17 10:34 ` Marcel Holtmann
2006-07-31 13:01   ` Marcello Cinque [this message]

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=44CDFF2D.9060003@unina.it \
    --to=macinque@unina.it \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.