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>