[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:bluetoothhacker@xxxxxxx.com] 
> Sent: Friday, January 11, 2002 22:38
> To: BlueZ Mailing List
> Cc: bluetooth-dev@xxxxxxx.com
> 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
> campaigns.
> 
> BlueZ:
> 
> Advantages:
> 
> * Included in the Linux kernel since 2.4.6 as the alpha test
>   modules 
> * 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.
> 
> Axis: 
> 
> Advantages:
> 
> * 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) 
>   http://mhonarc.axis.se/bluetooth-dev/msg02503.html 
> * 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.

> Argument: 
> 
> * 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
>   http://mhonarc.axis.se/bluetooth-dev/msg01889.html 
> * 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. 
> 
> Regards,
> 
> David

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