> Why not just use a "streaming" client interface, like ACM or the serial > driver instead of treating a filesystem not like a filesystem? One of requirements of the product I'm working on is that no Windows driver installation be required. > > You've got an unusual setup. Most people just stick a filesystem on > > the gadget and use it that way. > Yes, but what's to prevent a host from treating this like a filesystem > and use it that way? What happens if you plug this device into a > windows machine without your special host software, or a OS-X or Linux > machine? Actually, we need Windows to treat our Linux device to as a filesystem so that the user can load and run the special Windows software that's embedded in the backing file. The Windows software then reads/writes to what it sees as a 512kb contiguous data file (literally called "data") in the exposed file system. On the Linux device, our service does a look up of the offset of the contiguous "data" file in the backing file and does it's reads and writes from there. Rob -----Original Message----- From: Greg KH [mailto:greg@xxxxxxxxx] Sent: Thursday, August 19, 2010 3:37 PM To: Alan Stern; Murphy, Robert; Hardy, Ron Cc: linux-usb@xxxxxxxxxxxxxxx Subject: Re: FW: Concerns regarding file backed storage gadget On Thu, Aug 19, 2010 at 04:25:57PM -0400, Alan Stern wrote: > On Thu, 19 Aug 2010, Murphy, Robert wrote: > > > Yes, we have done extensive testing in this area and have things working well. Just to clarify, we are considering the USB client as the Linux device which has the backing file and the USB host as the PC (Windows). > > > > During the initial development, we did run into "cache > > coherency"-like issues in Windows. We found that if we changed the > > contents of the backing file from the client, the host (Windows) > > would never read the new data. However, we found that in Windows, > > if we opened the file with the FILE_FLAG_NO_BUFFERING attribute set, > > Windows would always read (and write) the latest data from (or to) > > the device (instead of its local cache). > > > > The mechanism works as follows: > > We have set aside a 512kb portion of the backing file as a ring > > buffered transfer area which is split into buffers for host to > > client writes and client to host writes. Again, all host > > reads/writes are non-cached. When the host wants to transfer some > > data, if first does a read of the host to client ring buffer index > > and then performs writes to the currently unused ring buffers. The > > opposite works for client to host. Why not just use a "streaming" client interface, like ACM or the serial driver instead of treating a filesystem not like a filesystem? > > > > We've tested this functionality on a few Windows 7 and XP systems and haven't seen any issues yet. > > > > Given all this, is there any reason to believe there could be a possibility of stability issues on either side (PC or Linux)? > > In fact this sounds okay. You're not using the device to hold a > filesystem and the host knows not to cache the data, so it won't get > confused if the data changes without its knowledge. > > You've got an unusual setup. Most people just stick a filesystem on > the gadget and use it that way. Yes, but what's to prevent a host from treating this like a filesystem and use it that way? What happens if you plug this device into a windows machine without your special host software, or a OS-X or Linux machine? That would cause problems, right? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
