On Tue, 2007-01-30 at 05:05 -0500, Chris Frey wrote:
> On Mon, Jan 29, 2007 at 05:21:39PM -0800, Greg KH wrote:
> > Also, would it make sense to provide a userspace "pipe" to this device,
> > so that the userspace tools can just open a device node, instead of
> > messing around with usbfs?

I would like to see this, then we could treat the usb device the same as
the serial/bluetooth device, however, the main problem I've seen with
this so far is the authentication process. The serial/bluetooth make you
authenticate on the device, the usb authenticates on the host :( With
the kernel driver you could create a device for sync/backup, and one for
the GPRS access, as well as setting the power level. In the end, I would
like to be able to "cat </dev/blackberry/20098fa9/Address Book/Rick
Scott/PIN" to retrieve my pin, similarly to set new entries. In other
words, treat the various databases like a filesystem that you could
browse.

> 
> Barry is intended to be a userspace library for accessing the Blackberry,
> and all we need besides the initial control messages are the Bulk
> transfers.
> 
> The main place the kernel could help, in my view, is arbitrating between
> the proprietary Blackberry interface (class 0xFF) and the Pearl
> mass storage (class 8).  But this is a user space decision as well,
> as I don't think both can be used at once. (?)  I'd love to be wrong on that.

A driver would also help with the RIM Desktop and RIM_UsbSerData modes.
Allowing different applications to use these at the same time. This may
get further blurred when they implement the bluetooth network stack
along with the serial profile ....

> 
> I don't think a kernel driver for the Blackberry is needed, but even if
> we do decide to go that route someday, I think it is too soon at this point.
> The database access protocol is mostly reverse engineered and working,
> but things like Java program uploads I haven't gotten to, and I'm not
> aware of anyone else who has reverse engineered that yet.  Even the
> database protocol has had new discoveries as recent as last week.  Once the
> Barry library is stable, I could see designing a proper kernel driver
> for it if there was a need, but at the moment, it seems early to me.

Being a little early, I fully agree with. We haven't even decided
whether Barry, or XmBlackBerry is the way to go :) If RIM takes up
Greg's offer, that I saw on /. today, this all may become crystal clear.
But at the moment, even pushing the power switch stuff into the kernel
seems a little dangerous to me. There is a lot we do not know about the
myriad of devices RIM has out there ....

> 
> - Chris
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Barry-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/barry-devel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to