From owner-freebsd-bluetooth@FreeBSD.ORG Sun Jun 18 07:04:59 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C3D116A479 for ; Sun, 18 Jun 2006 07:04:59 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08E8B43D46 for ; Sun, 18 Jun 2006 07:04:58 +0000 (GMT) (envelope-from plunky@rya-online.net) Received: from rya-online.net (du213-130-142-51.as15444.net [213.130.142.51]) by mail.ukfsn.org (Postfix) with SMTP id 3281FE70D6; Sun, 18 Jun 2006 08:04:45 +0100 (BST) Received: (nullmailer pid 22481 invoked by uid 1000); Sat, 17 Jun 2006 19:08:07 -0000 Date: Sat, 17 Jun 2006 20:08:06 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: <44931C12.7020805@savvis.net> References: <1150200307.649295.228.nullmailer@galant.ukfsn.org> <44904A60.6080105@savvis.net> <1150322381.757072.1713.nullmailer@galant.ukfsn.org> <4492E9FA.2030708@savvis.net> <1150486990.380039.25644.nullmailer@galant.ukfsn.org> <44931C12.7020805@savvis.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1150571287.231614.2893.nullmailer@galant.ukfsn.org> From: Iain Hibbert Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 07:04:59 -0000 On Fri, 16 Jun 2006, Maksim Yevmenkin wrote: > i'm not sure why is it required to parse all the data and re-pack it into the > linked list, just to have another api that would search and extract data from > the linked list. I agree, and I dont like the plethora of functions that they use. Better I think to have a generic function and pass it an argument telling it what to look for, that way its easily extensible. > i had a chance to work with csr bluelab sdk recently and develop the I guess this is a proprietary system, but do they have a public API? My thought for a parse function would be to pass an array of some kind, describing the attributes and possible values that are wanted, plus the address of the storage location, so to find the HID control and interrupt PSM values you just go something like this: uint16_t control_psm, interrupt_psm; sdp_parse_t values[] = { { SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST, { UUID, SDP_UUID_PROTOCOL_L2CAP }, { UINT16, &control_psm } }, { SDP_ATTR_ADDITIONAL_PROTOCOL_DESCRIPTOR_LIST, { UUID, SDP_UUID_PROTOCOL_L2CAP }, { UINT16, &interrupt_psm } } }; nvalues = 2; control_psm = 0; interrupt_psm = 0; err = sdp_parse(pdu, &values, nvalues); if (err || control_psm == 0 || interrupt_psm == 0) ... and this should be easily extensible for whatever you want to extract. The array can be static and const. It could be that you could specify mandatory/optional values and have the sdp_parse fail if mandatory fields are not accounted for. I didnt think about it too deeply, just the general concept. There can no doubt be a bunch of complications.. and thinking about it, if the same concept could be used to *construct* a PDU I would be especially pleased.. iain