Re: [9fans] bluetooth
anyone looked at this or given it any thought? I've been working on a bluetooth implementation which should be ready for initial release soon. Just the core communication layers (usb-hci transport, hci, l2cap, rfcomm), and fairly rudimentary: I've tried to pick a minimal useful subset rather than support the whole 1420-page Core V2.1+EDR standard. The interface follows the normal Plan 9 /net model, so the usual dial/announce/listen operations work pretty much as expected, and you can do things like: aux/listen1 bt!*!77 /bin/exportfs import -A bt!00123456789A!77 / /n/blue A bit of tweaking to cs(8) would allow the use of friendly device names in place of 12-hexdigit bluetooth device addresses.
Re: [9fans] bluetooth
A very superficial glance a long time ago suggested that it was a twisty little maze of de-facto and de-vulgus standards. i.e. the death of a thousand committees. The core standard (defining the communication layers) is actually not too bad, compared to some I've had to look at. It's huge, but a lot of it is describing low-level radio stuff (below the hci layer) which your bluetooth chip takes care of. All the profiles (application layers) have their own separate standards documents, and there indeed is a morass of (non)design by committee. Then there's the hardware ... Maybe I was lucky, but my random choice of development hardware (a cheap generic usb dongle with a CSR chip) has seemed to behave just as the spec says. Of course there have been surprises, but so far these have been where the spec was ambiguous and my guess didn't match the firmware designer's guess.
Re: [9fans] bluetooth
aux/listen1 bt!*!77 /bin/exportfs import -A bt!00123456789A!77 / /n/blue beautiful!
Re: [9fans] bluetooth
import -A bt!00123456789A!77 / /n/blue what does the device id discovery look like?
Re: [9fans] bluetooth
If it's useful, I'd love to beta test or alpha test or whatever. thanks a lot for your effort!
Re: [9fans] bluetooth
what does the device id discovery look like? At present: echo inquiry M N /net/bt/ctl (spend up to M seconds looking for up to N devices) cat /n/bt/devices (see what devices have been found)
Re: [9fans] 9vx (is this the right list)? import issue
So just need to fix oserrstr() or fix this in devip itself? I vote oserrstr, lucho votes fix this little bit of code. how many other errors are lurking in osstrerror()? there are lots of assumptions about the exact errstrs. - erik
Re: [9fans] 9vx (is this the right list)? import issue
sent in via codereview but I missed a debug print I left in. Sorry. I assume you can reject it so I'm sending the correct patch. ron
Re: [9fans] 9vx (is this the right list)? import issue
not having done this before, the reference is URL: http://codereview.appspot.com/122046 ron
Re: [9fans] 9vx (is this the right list)? import issue
On Wed Sep 23 14:54:47 EDT 2009, r...@swtch.com wrote: how sure are we that 1 holds? couldn't there be other, legitimate and transient errors? could a user-delivered note sneak in and confuse the issue? no. at least not if the kernel is working properly. that's why i said devmnt should enforce the assumption. it's at most a couple lines of extra code, whereas the diff you posted was quite a bit longer. it seems to be a big assumption that the whole ip stack and the ethernet driver know the difference between being interrupted before sending or queuing the packet or after. the comment in qbwrite seems to say that you can get interrupted after the pkt has been queued. my approach has the advantage of sidestepping this problem. i don't think 13 changed lines is unreasonable. (without verbose debugging.) - erik
Re: [9fans] 9vx (is this the right list)? import issue
On Wednesday, September 23, 2009, ron minnich rminn...@gmail.com wrote: not having done this before, the reference is URL: http://codereview.appspot.com/122046 Thanks, Ron. Fix applied. Russ
[9fans] myricom 10gbe update
with the help of the great folks at myricom, we've been able to find a couple of performance limitations and fix a few bugs. we were able to transfer aoe at 1GB/s between two modest (3 year old) 1.86ghz intel 5000 xeons. contrib quanstro/etherm10g this patch uses the vmappat patch which is now out-of-date. a redo is available at /n/sources/contrib/quanstro/patredux. this patch is not required but helps if you are using small packets. by small, i mean 8k. to remove, just turn vmappat to vmap without the 3d arg. since we are not using msi interrupts, the coal parameter (interrupt coalesing) is fairly sensitve. this is because the dance even mp interrupts need to do takes many cycles. it's amazing how many apics, i/o apics and other nonsense is involved on a modern pcie machine. i have used values from 15-50µs with the current code. ymmv. - erik
Re: [9fans] bluetooth
thank you for doing this. like nemo, i'd like to offer testing. To echo nemo and skip, I do own one USB bluetooth radio and many mobile handsets. Count me in, if you wish. ++L
