e.Digital Corporation (fka EDIG)

[gernb1]

Interesting...I am writing a USB device driver for the Dataplay device for the Linux kernel. Note that I don't work for Dataplay. I just work for a company that wants to use this device from Linux. This is my first device driver I've written. I've done some debugging and testing with other USB drivers, but never authored one myself.

The Dataplay drive uses small (3cm) removable optical disks that store 250MB on each side. It uses a write-once or append only type interface. The biggest kick is that it implements digital rights management (DRM). The filesystem code is embedded into the device. It doesn't present a block interface at all. The API is totally based at the file level.


On the Dataplay Bankruptcy
Yes, Dataplay officially went bankrupt in Oct 2002. If you haven't heard, they have been bought by DPHI, Inc. and are opperating again. At the time of this writing (August 2003) they are fully functional and selling Dataplay devices again. They have every hope and intention of surviving. I personally know several of the engineers and have met the new owner/CEO/President Bill Allman. All in all (no pun intended), I have more confidence in them as a company than ever.


Code Management
I tossed around several times what to do about code management. It seems like an overly complex thing to try and do code management on the kernel while keeping up with or accepting code from various places (like the kgdb or uml patches). I think if I had it to do all over again, I would just use CVS and maintain all the various patches as vendor branches. I tried BitKeeper? for a long while (in fact you can see my project at http://dataplay.bkbits.net/). I had lots of problems because: 1) the two sets of patches I was interrested in weren't maintained in a BK tree anywhere; 2) the USB sub-system maintainer's BK repo wasn't parented by either Marcello or Linus' trees.

So, anyway, you'll find the latest patch below. For the time that's what I'll do.

Well, since this is officially a work project, they wanted the code maintained better than just a series of patches. That meant throwing it in our CVS tree for all practical purposes. Rather than putting all of the linux kernel source in the CVS tree I pulled my module out into a stand-alone compilation unit. That allows me to make a tarball pretty easily of everything you need to build it.

Of course, to get this driver into the official kernel I'll need to merge it back into the kernel source again. However, there are a lot of other things I'll need to do first.


Current status
As of May 2003 I'm "golden". The driver basically does all the simple things I need it to. The bad news is that I'm not allowed to release the code for all the file i/o stuff. The kernel driver implements the Dataplay custom protocol for encapsulating their file i/o commands into the USB protocol. So, you still need to know the "proprietary" file i/o commands from Dataplay themselves in order to make any use of this driver. I implemented this file i/o stuff as a userland library all using ioctls. My userland library works well. I can pretty much do whatever I want on the media in an unencrypted maner.

Note that there will probably never be any open source tools to take advantage of the built-in encryption on the Dataplay drive. Don't talk to me about such things. It's not my product.

All is not lost though. I've been told that Dataplay would very much like to see an open source filesystem driver for their stuff. The problem is that they don't have the manpower to write it. They've told me they'd be more than glad to help support me while I wrote it. Of course, "support" doesn't mean "hire". It just means answer my questions. I'm sure if anyone else came along and thought they could write the filesystem they'd extend the same offer.


Warnings
I know the driver won't work with SMP. It won't even compile. Don't enable SMP in your config. Sorry, I'll get to fixing that once I figure out the right way to use spin_locks


I'm getting a race condition/deadlock in the driver occationally. I suppose I should detail all the testing I've done to narrow it down. Maybe someone could come and fix m yproblem for me . In summary, it appears that with some engines and some kernel configurations after several thousand write commands the driver hangs while waiting for the status packet to be read. I really suspect this is due to my less than stellar understanding of locking. Version 0.9.3.2 has a re-implementation of my locking strategy. It doesn't fix my hang, but it's easier to understand.