[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [bluetooth-dev] An comparison between BlueZ and Axis
> -----Original Message-----
> From: Yong David [mailto:email@example.com]
> Sent: Friday, January 11, 2002 22:38
> To: BlueZ Mailing List
> Cc: firstname.lastname@example.org
> Subject: [bluetooth-dev] An comparison between BlueZ and Axis
> Hi all Linux Bluetooth hackers,
> I have done some kind of comparison between BlueZ and Axis,
OpenBT, not Axis. Axis is the name of the company behind OpenBT.
> just for the purpose of learning more about Linux and Bluetooth.
> I am very sorry if it starts some kind of argument between two
> * Included in the Linux kernel since 2.4.6 as the alpha test
> * Socket interface to lower layers
> * Efficient frame processing (multi threading ,etc)
> * Endianess independent (The pattern for byte ordering in
> native types, such as integers)
> * Good modularity
> * Support as many devices on one PC as we want (my experiment
> for initialization done, but the communication not yet)
> * Porting other stacks to fit the Bluez's need. For instance, Porting
> RFCOMM engine, http://mhonarc.axis.se/bluetooth-dev/msg01892.html.
> SDP from Openbt, and porting original VTun by replacing the UDP
> with L2CAP.
> * Design based on the kernel 2.0.x and above.
> * Has working production using the openbt stack Bluetooth
> Access Points running embedded Linux (2.0.36)
> * First open source Linux Bluetooth stack. Large amount of CVS
> modification and verification, more versions released.
> * BCSP protocol is not supported
I suppose you mean that BCSP _is_ supported, which it is.
Also, OpenBT is supposed to be endian-safe. If it isn't, then
that's a bug.
> * BlueZ: emulating TTY functionality would completely inefficient.
> Current BlueZ interface is clean and simple. Stack uses SKBs (skb -
> Linux network buffers http://www.gnumonks.org/ftp/pub/doc/skb-doc.html)
> on all layers. SKBs are different from kmem_alloc (The kernel-memory
> allocator. More...) because they are SLABified which means that
> there is a cache for SKB heads and allocations are optimized.
> Also SKBs provide lots of nice optimized functions and queues, so
> reinventing the wheel is not necessary
> * Axis: emulating TTY functionality is meant for the compatibility and
> interoperability with other stacks and applications.
> I'm not clear as to how to use the BlueZ stack to get support for
> "legacy" applications - i.e. those that are written to use /dev/ttyxx (*nix),
> Does BlueZ have some kind of compatibility and interoperability problem?
> Why Axis uses the stream socket and BlueZ use the raw socket?
> I read that "in the long run, raw sockets have proven bug ridden,
> unportable and limited in use." http://www.whitefang.com/rin/rawfaq.html#20.
> Is that a problem for BlueZ?
> Please give me some help on it. Thanks a lot.
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to email@example.com