Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Jun 2002 10:39:35 -0700 (PDT)
From:      Maksim Yevmenkin <m_evmenkin@yahoo.com>
To:        Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc:        Harti Brandt <brandt@fokus.gmd.de>, Terry Lambert <tlambert2@mindspring.com>, current@FreeBSD.ORG
Subject:   Re: Device cloning 
Message-ID:  <20020611173935.84573.qmail@web13305.mail.yahoo.com>
In-Reply-To: <52544.1023815855@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help

> >I'm sorry people :) I should have been more specific. Here is
> >what i meant. I'm working on Bluetooth stack for FreeBSD. Everything
> >is implemented in Netgraph. The real device driver nodes are connected
> >to HCI layer. You can talk to any Bluetooth device via HCI layer. It
> >does not really matter what kind of device you have, PC-CARD, serial
> >or USB dongle. They all MUST talk via HCI. So HCI is not really a
> device driver, and, IMO, it is not a pseudo device driver. It sort
> >of looks like /dev/tcp :)
> 
> That's called a "protocol family" in BSD and you access it using
> sockets.

Well, HCI _IS_NOT_ a network protocol like TCP or even UDP. It is a
predefined set of control messages and events that user might send
to the device. L2CAP which is runs over HCI _IS_ a network protocol
and it is implemented in AF_BLUETOOTH protocol family. So application
can say s = socket(AF_BLUETOOTH, SOCK_SEQ, BTPROTO_L2CAP) and then
bind(s) and connect(s).

> Based on what little I know about "Blåtand" it will be much easier
> to work with as a socket than as a /dev/bla entry.
> 
> >Currently there is a single "control" hook for every HCI node. Control
> >application connects to the hook and sends HCI commands and receives
> >HCI events. It does work, but once the hook is connected, nobody else
> >can connect to the same hook. That is a limitation, IMO. It would 
> >really be nice to have several control applications. For example,
> 
> This is exactly the kind of semantics sockets offer you.
> 
> >2) Raw HCI sockets
> >
> >   The problem here is how to identify device, i.e. what to put
> >   into sockaddr? Netgraph node name? May be not a good choice,
> >   because it can be changed at any time. Device BD_ADDR? Does not
> >   work also, because in order to get BD_ADDR you must send HCI
> >   command to the device.
> 
> Well, many TCP clients don't care about the name, so they ask
> for INADDR_ANY and get whatever the kernel feels like giving them,
> you could do the same and have the kernel hand out random numbers.

Again, i have to ask specific device on _HCI_ layer. Here is an
example. User plugged the card. Now HCI layer MUST query the card
and ask 

- what is the BD_ADDR (MAC) ?
- what are the capabilities of the device?
- what is the size of the data buffer?
- etc.

HCI layer _has_ all this commands defined. In fact control application
sends several HCI commands to the device to initialze it. After
device is connected to the stack - no problem - you now can use
BD_ADDR in sockaddr and do whatever you want to do.

thanks,
max


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020611173935.84573.qmail>