Date: Wed, 10 Jun 2009 11:06:21 +0100 (BST) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: freebsd-bluetooth@freebsd.org Subject: Re: bt_dev API Message-ID: <1244628381.118410.14961.nullmailer@galant.ukfsn.org> In-Reply-To: <1244621794.486063.830.nullmailer@galant.ukfsn.org> References: <1244571487.241431.980.nullmailer@galant.ukfsn.org> <bb4a86c70906091524p507181b4l3ddd45e0e22b6fe1@mail.gmail.com> <1244621794.486063.830.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1244628381.118410.14961.nullmailer>