bt_dev API

[Iain Hibbert]

Hi Max,

Are you still with us? After some delay (and a tan from last week :) I am
about ready with the bt_dev stuff for NetBSD now (latest dump at
www.netbsd.org:~plunky/btdev-20090609.tar.gz)

some questions re API still to be resolved though

- bt_devopen(name, flags) flags argument?
BTOPT_DIRECTION
BTOPT_TIMESTAMP

- bt_devclose(s) should not be required?

- ssize_t bt_devsend() return number of bytes sent?

- bt_devinfo(name, info) add name argument?

- struct bt_devinfo state field needs to be genericalised,

regards,
iain

[Maksim Yevmenkin]

Iain,

> Are you still with us? �After some delay (and a tan from last week :) I am
> about ready with the bt_dev stuff for NetBSD now (latest dump at
> www.netbsd.org:~plunky/btdev-20090609.tar.gz)

sorry. i'm completely swamped at $real_job :(

> some questions re API still to be resolved though
>
> - bt_devopen(name, flags) � � � flags argument?
> � � � � � � � � � � � � � � � � �BTOPT_DIRECTION
> � � � � � � � � � � � � � � � � �BTOPT_TIMESTAMP

i guess its fine, but i still kinda like setopt() call.

> - bt_devclose(s) � � � � � � � �should not be required?

i'd like to just keep it for clarity. we can turn it into #define if needed

> - ssize_t bt_devsend() � � � � �return number of bytes sent?

sure

> - bt_devinfo(name, info) � � � �add name argument?

no problem

> - struct bt_devinfo � � � � � � state field needs to be genericalised,

i have not look at the source. i'm guessing its probably fine too :)

thanks,
max

[Iain Hibbert]

On Wed, 10 Jun 2009, Iain Hibbert wrote:

> > > - struct bt_devinfo state field needs to be genericalised,
> >
> > i have not look at the source. i'm guessing its probably fine too :)
>

> I'm still thinking about how best to do that, will look at the linux
> sources later to see what might fit. I'm thinking that either

Ok, BlueZ has a HCI_UP flag that they use to mean device enabled, NetBSD
has BTF_UP and FreeBSD has 'state == connected' to mean the same thing (?)

So, I propose the simplified 'publicly documented' interface as follows

--

Obtain information from a Bluetooth device present in the system.
The
.Fa info
argument is a pointer to a
.Ft bt_devinfo
structure into which information about device
.Fa name
is placed.
The
.Ft bt_devinfo
structure contains at least the following fields:
.Bd -literal
char devname[HCI_DEVNAME_SIZE];
int enabled; /* device is enabled */

/* device information */
bdaddr_t bdaddr;
uint8_t features[HCI_FEATURES_SIZE];
uint16_t acl_size;
uint16_t sco_size;

/* flow control */
uint16_t cmd_free;
uint16_t acl_free;
uint16_t sco_free;

/* statistics */
uint32_t cmd_sent;
uint32_t evnt_recv;
uint32_t acl_recv;
uint32_t acl_sent;
uint32_t sco_recv;
uint32_t sco_sent;
uint32_t bytes_recv;
uint32_t bytes_sent;

/* device settings */
uint16_t link_policy_info;
uint16_t packet_type_info;
uint16_t role_switch_info;
.Ed
.Lp
Because a Bluetooth device must be enabled in order to retrieve
information, the
.Fa enabled
flag should be tested to be non-zero before relying on further data.

--

So, I dropped all the struct padding as no caller needs to care about it,
plus acl_pkts and sco_pkts as from what I can see, they are not properly
available (only FreeBSD provides such a 'max' value but its not really
part of the HCI spec, devices will only ever provide 'current' value)

thoughts?

iain

[Iain Hibbert]

sigh, that is wrong, they come from HCI_CMD_READ_BUFFER_SIZE of course..

iain