Date: Thu, 16 Apr 2009 09:46:09 +0100 (BST) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org> Subject: Re: libhci update Message-ID: <1239871569.560012.1086.nullmailer@galant.ukfsn.org> In-Reply-To: <bb4a86c70904151359y3dcf9627u6f30528f07c7252c@mail.gmail.com> References: <49D92E26.2030508@incunabulum.net> <bb4a86c70904061358l3983ed51m11265859a833f202@mail.gmail.com> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> <bb4a86c70904091013l2d7c2b77ic7f6988e6e7709f2@mail.gmail.com> <49DE4E2F.2000805@incunabulum.net> <bb4a86c70904091337x7061ab5uf57bbaff1d5f3197@mail.gmail.com> <49DE6D42.6000004@incunabulum.net> <bb4a86c70904091537x1c6ec085r877d847268b38d3e@mail.gmail.com> <bb4a86c70904151359y3dcf9627u6f30528f07c7252c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 15 Apr 2009, Maksim Yevmenkin wrote:
> please find attached patch that implements more compatibility shims.
> any comments are greatly appreciated.
+int
+bt_devsend(int s, uint16_t ogf, uint16_t ocf, int plen, void *param)
One thing that I did when writing the NetBSD stack which IMHO made source
somewhat cleaner was provide HCI_CMD_xxxx definintions that included the
OGF and OCF directly, eg
#define HCI_OGF_LINK_CONTROL 0x01
#define HCI_OCF_INQUIRY 0x0001
#define HCI_CMD_INQUIRY 0x0401
It could be considered a remote possibility of a namespace conflict (ie
same command in different groups) but I doubt that it will ever happen
(and would be easily handled). That would make this into
+int
+bt_devsend(int s, uint16_t cmd, int plen, void *param)
thoughts?
Also, plen should be a size_t and it should come after the pointer, see
write, read, memcpy, snprintf etc for prior art :)
+int
+bt_devrecv(int s, uint8_t *buf, int size, time_t to)
and ditto for size_t here
+int
+bt_devinquiry(char const *devname, int length, int num_rsp,
+ uint8_t const *lap, struct bt_devinquiry **ii)
I wonder if allowing for a different LAP is at all useful? I would say,
for the very remote possibility that somebody wants to do that, they could
just cut and past the code..
Also with inquiry, would it make sense to just pass a time_t and calculate
the 'inquiry length' internally?
+struct bt_devinquiry {
+ bdaddr_t bdaddr;
+ uint8_t pscan_rep_mode;
+ uint8_t pscan_period_mode;
+ uint8_t pscan_mode;
+ uint8_t dev_class[3];
+ uint16_t clock_offset;
+};
Does this structure need to be a direct copy of the inquiry result?
page_scan_period_mode and page_scan_mode are deprecated since a long time
so its probably not worth providing the values (most devices return 0
that I've seen).
We also need to [be able] to handle the inquiry-result-with-rssi which
gives an extra int8_t RSSI value, and the 2.1 extended inquiry result
data. For both of those, I think its ok if they are zero if not provided.
(ie actual support can be added later)
struct bt_devinquiry {
bdaddr_t bdaddr;
uint8_t pscan_rep_mode;
uint8_t class[HCI_CLASS_SIZE];
uint16_t clock_offset;
int8_t rssi;
uint8_t data[HCI_EXTENDED_INQUIRY_DATA_SIZE];
};
?
+int
+bt_devfilter(int s, struct bt_devfilter const *new, struct bt_devfilter *old)
And finally, the HCI filter is slightly different in NetBSD (I provided
independent PKT and EVT filters each of 256 bits) and I'm going to think
about that..
regards,
iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1239871569.560012.1086.nullmailer>