On Wed, 2008-10-08 at 04:16 -0400, Chris Frey wrote: > On Mon, Oct 06, 2008 at 08:06:04PM -0400, Rick Scott wrote: > > I just noticed mention of a kernel driver in your TODO file. It just > > happens that I'm looking at that now. My thought is to create a device > > file for each "function". So for the first blackberry plugged in, you'd > > get bbdesktop0, bbmodem0, bbjavaloader0, and so on. The serial protocol, > > used in the older devices and bluetooth, is basically the same as what > > is sent over the "RIM Desktop" socket with a different header. So if the > > "RIM Desktop" packets are converted to the serial format and presented > > on bbdesktop0, anything to do with database access is the same > > on /dev/ttyS0, /dev/ttyUSB0, /dev/rfcomm0, /dev/bbdesktop0. The modem > > from /dev/rfcomm1, /dev/bbmodem1, and so on. This would give consistent > > access to all of the functions, whatever the means of connection. > > Hi Rick, > > It's a useful feature to have the ability to share a Blackberry USB > connection across multiple programs and multiple purposes. > > I think it is best to start at the lowest level we can, and we may > run into some roadblocks along the way. Especially the probe messages > that are not well understood yet. > > I think a kernel level interface that handles sockets and the opening > and closing of modes, is best. I'm quite against the idea of putting > record parsing in the kernel... I don't want to have to recompile my > kernel to get at a new Contact field, nor do I want to swim the depths > of the the kernel development process for something that is more quickly > updated in userspace.
I think we are on the same page here. My thought is to handle the socket 0 stuff in the module and have a device file created for all the other sockets that get opened. So far, "RIM Desktop" and "Usb_SerData". The desktop socket would peal off the usb type header, socket and length, and replace it with the serial header, 3 constant bytes and a checksum. That would give a consistent interface to the device on usb, bluetooth, and serial. Record parsing and a database "file system" would be better left to a fuse implementation, I think. It would be cool though, just cat a vCard into a file :) I've got a loadable module building outside of the kernel tree, so control would still be outside of the kernel process. Gotta run to pay the bills, more later .... > > But it *would* be very useful to do something like this: > > start a backup > start a tethered modem connection > end backup > start a javaloader transfer > start a restore > end restore > do a full sync of contacts and calendar > end javaloader > end modem > > There are some gotcha's in that list, I think. :-) Should be doable in > theory though. Take out the javaloader part and it's doable now. > > Thoughts? > > - Chris ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
