[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] Line collision between SDP and RF_COMM

> I think 'line' should be more related to baseband link, otherwise it 
> would waste the resources--the 'BT_NBR_DATAPORTS' is 7.  
Line is more a rfcomm concept, that's what the define is for to
set up 7 tty:s. You can have as many lines as you want over a 
the same basebandconnection (up to 63 with one single multiplexer).
MAX_NBR_OF_CONNECTIONS is however used to limit number of
basebandconnections. But as you say it will probably be a
waste of resources to have more than 7 lines at the same time.

> > SDP shouldn't use a line at all as we are running the 
> SDP-server -> OpenBT
> > communication through a procfile (in kernelmode). I guess 
> the line was
> > intended to be used for a SDP-client
> Yes, But it may have collision with RF_COMM which may get 
> same line and
> the stack will not check for it.

Yes I'm aware of this, I started to clean this up but haven't 
released it on sourceforge yet. 

> Although 'line' can/has to be used (in kernel mode)by SDP 
> client to get
> SDP connection, you can't use it the same way as for RF_COMM 
> such as to
> open /dev/ttyBTx (am I right here?). And I have no way to 
> disconnect it
> (kernel mode again) once it has been connected. It seems to me that
> it's remaining unfinished(SDP)--(I am using OpenBT 20010816 and I 
> checked its CVS site but no development on this issue).

It's true that you can't use it in the same way as rf_conn right now. The
problem is that we need functionality to receive sdp_data from the tty:s
(currently bt_write_top sends the data to the rfcomm layer),
but as I mentioned earlier this should really be handled by a socket and not
mix it with the rfcomm-lines. There is probably some more work to be done with
the client parts of the stack. OpenBT was originally developed for use with 
our access point and therefore the functionality as a client stack isn't complete (yet) :).
We probably need some more IOCTL:s to be able to, as example, disconnect a SDP-link. 
Currently BTDISCONNECT assumes that you have a line for the connection and this is
only true for rfcomm-connections.

> > but personally I think a socket
> > is more suitable for this.
> > 
> > Best Regards
> > Anders Johansson
> > -

To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com