Re: netbt, Bluetooth kernel code
On Sat, Jul 13, 2013 at 02:52:02AM +0100, Tony Sidaway wrote: On 13/07/2013, Theo de Raadt dera...@cvs.openbsd.org wrote: Whoa. I think USB was just called a good model. Good? I'm not sure on that point. A better idea for a model? Yeah, kind of like much less worse. I'll readily study any better model. But let's be realistic. I've already started studying USB and I'm prepared to apply any useful principles I find there in future code that may be submitted to OpenBSD. If there is a good argument for further development of Bluetooth in OpenBSD, in any case, it won't just be my enthusiasm. I think one of the main points is that netbt is behaving like a network stack even though it is not. The result is a strange network layer and to some extents abuse of network resurces for something that is not network related -- using mbufs as a buffer backend comes to mind. -- :wq Claudio
Re: netbt, Bluetooth kernel code
Making it better requires a bigger effort. However, ones you get part way along the line you might see oh, lower level abstration good. If you get to that point, and make the next steps forward, you'll be a hero. Thanks. I've received several helpful comments and contributions from others who are interested in this, but I appreciate the broad delineation of what experienced OpenBSD developers view as an acceptable standard for kernel device driver subsystem code. Thanks for the encouragement. I'll continue to study the USB code Ted recommends as a good model. Whoa. I think USB was just called a good model. Good? I'm not sure on that point. A better idea for a model? Yeah, kind of like much less worse.
Re: netbt, Bluetooth kernel code
On 13/07/2013, Theo de Raadt dera...@cvs.openbsd.org wrote: Whoa. I think USB was just called a good model. Good? I'm not sure on that point. A better idea for a model? Yeah, kind of like much less worse. I'll readily study any better model. But let's be realistic. I've already started studying USB and I'm prepared to apply any useful principles I find there in future code that may be submitted to OpenBSD. If there is a good argument for further development of Bluetooth in OpenBSD, in any case, it won't just be my enthusiasm.
netbt, Bluetooth kernel code
I'm working on the netbt and /dev/bluetooth code, which is currently broken and has been disabled in the generic kernel for over a year now. I'm not an experienced BSD developer (yet) so I'm using this code as a way of learning how to debug and fix major problems. I'm also working on updating the OpenBSD 5.0 ports bluetooth-libs and bluetooth-tools to build and run on OpenBSD-current. Libs now builds, Tools needs a rewrite of the Unix socket credentials check. The NetBSD Service Discovery Protocol code still uses SCM_CREDS/struct sockcred, and this has been removed from the OpenBSD tree as obsolete. But a moved to SO_PEERCRED should work there. So hi, and if there's anybody else looking at this code, please get in touch. I hope I'll be able to fix the problems of the device sleeping in mutexed code. If there is a high likelihood that this code will soon be removed from the tree, that would be nice to know too. Maybe I could change that.
Re: netbt, Bluetooth kernel code
On Thu, Jul 11, 2013 at 21:46, Tony Sidaway wrote: So hi, and if there's anybody else looking at this code, please get in touch. I hope I'll be able to fix the problems of the device sleeping in mutexed code. If there is a high likelihood that this code will soon be removed from the tree, that would be nice to know too. Maybe I could change that. There is a sentiment among some developers that the current code is too network heavy. Perhaps it should look more like the usb code. But the existing code shouldn't go anywhere until there is a replacement, and I don't think there are any yet. So fixes to the existing code would be welcome.
Re: netbt, Bluetooth kernel code
So hi, and if there's anybody else looking at this code, please get in touch. I hope I'll be able to fix the problems of the device sleeping in mutexed code. If there is a high likelihood that this code will soon be removed from the tree, that would be nice to know too. Maybe I could change that. There is a sentiment among some developers that the current code is too network heavy. Concur. Perhaps it should look more like the usb code. Concur. But the existing code shouldn't go anywhere until there is a replacement, and I don't think there are any yet. So fixes to the existing code would be welcome. Concur. But it won't get enabled, even with bug fixes. Making it better requires a bigger effort. However, ones you get part way along the line you might see oh, lower level abstration good. If you get to that point, and make the next steps forward, you'll be a hero.
