Hi, On Wed, Jul 27, 2011 at 11:25:56AM +0200, Andrzej Pietrasiewicz wrote: > > I'm not sure this should be in kernel. Have you tried gadgetfs ? > > There are other gadgets in the mainline kernel which also > need cooperation from userspace. > > 1. g_file_storage - ideologically very close to dfu > 2. hid gadget - a character device is required to get input > from userspace > 3. uvc - not only does it require data input from user space, but also > requires setting up a userspace daemon for operation. > > So why not have dfu? It requires only a moderate interaction from > userspace - a module parameter (if it can be considered userspace at all) > and an entry in sysfs for each entity, which in a typical case will > probably be very few. > > DFU is a standard protocol. If, for example, a simple embedded device > is to be designed then having dfu at hand in kernel makes it a readily > available solution - the received data can be stored e.g. in /tmp. well, we can put it under tools/usb/dfud, or something... but it should not be a kernel driver. The fact that there are others, doesn't mean we should continue doing that. OBEX is also a standard protocol and despite we are still only providing a simple pipe to userland. MTP is a standard protocol and yet we have no MTP support in kernel at all (it uses gadgetfs). > Then the device's business logic need not concern itself with the internals > of gadgetfs/functionfs; it just needs to use a regular file to complete > its operation. gadgetfs will give you that file descriptor. Just make the thing pluginnable, so that you can run DFU on top of whatever you like. > DFU usage is easy on the host side as well - there are readily available > tools like dfu-util, so enabling it in kernel can make it become popular. still doesn't make it right though ;-) See Sebastian's mail where he points out the problems of accepting this into the kernel. -- balbi
Attachment:
signature.asc
Description: Digital signature
