From owner-freebsd-current Tue Jun 11 10:39:43 2002 Delivered-To: freebsd-current@freebsd.org Received: from web13305.mail.yahoo.com (web13305.mail.yahoo.com [216.136.175.41]) by hub.freebsd.org (Postfix) with SMTP id CBA3237B407 for ; Tue, 11 Jun 2002 10:39:37 -0700 (PDT) Message-ID: <20020611173935.84573.qmail@web13305.mail.yahoo.com> Received: from [206.220.224.4] by web13305.mail.yahoo.com via HTTP; Tue, 11 Jun 2002 10:39:35 PDT Date: Tue, 11 Jun 2002 10:39:35 -0700 (PDT) From: Maksim Yevmenkin Subject: Re: Device cloning To: Poul-Henning Kamp Cc: Harti Brandt , Terry Lambert , current@FreeBSD.ORG In-Reply-To: <52544.1023815855@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >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