Re: [Bluez-devel] Patch for bluez-hcidump-1.5

Max Krasnyansky wrote:

At 8:7 M 2/7/2002 -0800, Maksim Yevmenkin wrote:

quoted

i will try to make the first step and create hci.h and l2cap.h
that will contain only HCI and L2CAP types and defines - no system
specific code. the next step is to define API for Bluetooth sockets
(HCI and L2CAP), i.e. ioctl names, setsockopt defines etc. i also
propose to define common libBluetooth, libHCI (and probably libL2CAP)
API that will hide possible implementation differences. after we
do that all application just will use defined API and source code
will be 100% portable.

libL2CAP ?? We don't have libTCP/IP, do we ?
To much abstraction is _bad_.

:) i said *probably* :) there are still some differences in
L2CAP API. i have a different semantic for raw L2CAP sockets
for example. in order to send L2CAP PING and GET_INFO i use
ioctl() to avoid L2CAP command ID's collisions. the L2CAP
library could hide stuff like this. but then again - may be
its way too much abstraction :)

quoted

as for RFCOMM, SDP etc. then you guys will lead the parade :)
i'm currently using BlueZ code with the minimal changes. i'm just
hoping that SDP, RFCOMM etc. implementation won't become too
Linux specific :)

SDP should be portable.

amen :)

But RFCOMM TTY stuff will probably be different. How are you going to
implement it btw ?

i have not decided yet :( i have bigger problems now :( my
current plan is to make it completely in user space. FreeBSD
has the null-modem driver which will play the role of virtual
serial port. a service will start on the null-modem master's
side. a client will start on the null-modem's slave side. in
both cases rfcomm daemon will control other side of the
null-modem, monitor L2CAP socket and maintain rfcomm sessions. 
i'm also thinking about RFCOMM sockets module.

max