From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 24 Sep 2009 07:03:10 -0400 From: Nathaniel W Filardo To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20090924110310.GC22220@gradx.cs.jhu.edu> References: <3e4833291ef0dcb43052d394aa5231e1@9netics.com> <2be43af8bc6609589374bd4a7c625a7a@hamnavoe.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yYV7/xoJChL2XnxF" Content-Disposition: inline In-Reply-To: <2be43af8bc6609589374bd4a7c625a7a@hamnavoe.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [9fans] bluetooth Topicbox-Message-UUID: 76e8c246-ead5-11e9-9d60-3106f5b1d025 --yYV7/xoJChL2XnxF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 24, 2009 at 09:22:17AM +0100, Richard Miller wrote: > What do you mean exactly by "sees"? A device may be known > because it responded to an inquiry (probe for all devices) or a > page (probe for specific device), or because it sent you an inquiry > or a page, or because you paired with the device at some time in > the past and have a stored link key for it. [A device may be set Shouldn't factotum be in charge of storing keys? Or do you mean just keys that happen to be resident in the stack right now? > to respond to page but not inquiry. Or vice versa.] >=20 > > while (sleep 1) { > > echo `{ls /net/bt/ids}^'@'^`{date -n} > > } >=20 > The hardware can automatically do periodic inquiry scans in the > background. I could add a command 'inquiry auto N' to enable this > (but I guess you would still need a 'sleep' loop to look at the > devices file). >=20 > Advice sought: > 1. Would it be helpful to have a timestamp in the devices record to > give the time the device was last seen (for some value of "seen")? > 2. When should a device disappear from the /net/bt/devices list? How about exposing things as an ndb db so that we can add fields as the need arises? mac=3D00112233445566 name=3D"Friendly Name" !secret=3D0x... lastseen=3Dti= mestamp active=3Drfcomm3, sdp=3Dpan,rfcomm,...,... (that might be a bad example, if sdp is done by a separate daemon, e.g.; am just musing). What about letting me set a stored key by writing a line into this as a single write of "mac=3D... !secret=3D0x..." ala factotum's ctl file? Oh hey... why not make the file also act like the sound mixers and jccfs journals? That is, just stream events out to readers, starting with a full enumeration and then updates, then the "you are about to block" empty read, then block until the next scan or timeout which changes something. You can give an advisory signal (mac=3D... gone=3D or somesuch) that a devi= ce should be considered gone (and purge it from the list you'd report to a fresh client) after some small time interval... something between 5 and 30 seconds seems reasonable to me? People watching the event stream are free to do their own thing. Does that seem reasonable? --nwf; --yYV7/xoJChL2XnxF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkq7Ue4ACgkQTeQabvr9Tc9eAQCfQfvG0W0CrsCn3lKbd1phplZv j+IAn1U1hNtlRqUyXVLimqIaUD3xWsKH =8Y+b -----END PGP SIGNATURE----- --yYV7/xoJChL2XnxF--