On Fri, 10 Mar 2006, Steven M. Bellovin wrote:

> On Fri, 10 Mar 2006 09:26:50 +0000 (GMT)
> Iain Hibbert <plunky@rya-online.net> wrote:
>
> > There are other incompatibilites in any case, though porting programs is
> > usually a bit of cut and paste and a lot of it could be handled with
> > #define. I'm not sure what application level software is available but
> > that would not usually need to access HCI devices directly, though there
> > was some chat on the FreeBSD list a while ago about creating a library API
> > to abstract some of that which could make sense.
>
> This is the real question.  What could -- or should -- show up in
> pkgsrc in two years?  How much harder will this difference make it to
> port such programs?

Well, I would think not much.

The biggest difference is in HCI raw socket addressing (because nobody
else seems to use device address), and at that level the only programs are
configuration programs, which would tend to be NetBSD specific. There are
differences between all the open source stacks that I could see at this
level in any case.

Normally applications would open an L2CAP (seqpacket) or RFCOMM (stream)
socket, and the differences would be minimal there, though there are
certain differences between linux and BSD socket addressing at the best of
times (they have no length field).

One of the problems that I think the FreeBSD guys are seeing is that the
newer Gnome and Kde 'bluetooth' suites are being built directly around the
BlueZ/Linux API and I dont think they especially have interoperability
high up on the list. Unfortunately, the BlueZ addressing at that level is
typically Linux..

struct sockaddr_hci {
	sa_family_t	hci_family;
	unsigned short	hci_dev;
};

..and you would have to kill me first.

iain