Future of dfu-util

[Sandro Giessl]

Hi Stefan,

I, too, am glad you stepped up.

Am Sonntag, 25. April 2010 16:50:25 schrieb Stefan Schmidt:
> Short Term
> ----------
> - Include some minimal fixes
> - Good testing with different u-boot versions
> - Perhaps some initial fixes for other devices
> - Release candidate (2010-05-16)
> - Release 0.1 (2010-04-23)
> - Work with the packagers to get it into the distros
>
> Mid Term
> --------
> - Go through the OM bug tracker and find bugs for dfu-util and the u-boot
>   counterpart
> - Get access to OpenPCD hardware and test the current code with it
> - Prepare a subdomain for hosting at gnumonks (e.g. dfu-util.gnumonks.org)
> - Import the SVN history into a git repo and move on with it
> - List with supported devices
> - Minimal website with this list and a description
> - DFU file suffix handling
> - Quirk infrastructure based on product IDs (e.g. timeout handling)
> - Fix DFU upload in u-boot
> - UI: show endmarker in status bar and/or show percentage
> - Check if we can use --static for the static version
> - Relase candidate
> - Release 0.2 (June?)
> 
> Long term
> ---------
> - Merge u-boot DFU patches in u-boot mainline
> - DFU runtime descriptor in linux gadget composite framework
> - Test more devices (e.g. bt adapter, iphone/ipod, ...)
> - Maybe a nice logo?

This looks all quite sensible to me.

> Some thoughts are not on dfu-util only but about the ecosystem around it. I
> think we would profit not only from a solid DFU host implementation but
>  also the devices counterparts where we have access to the source code.
> 
> Help is of course appreciated in all areas. Daniel and Sandros have already
> indicated that they will work on DFU suffix handling and maybe the quirk
>  system.

Proposing patches didn't work out as priorities have shifted a little bit 
again. :( Anyway, it is Mid Term stuff.
There are some draftings I put on http://github.com/sgiessl/dfu-util-branch/ 
containing a minimalist's approach to quirks, unfinished dfu-suffix handling, 
bmAttributes-handling such as bitWillDetach and mostly minor structural 
changes otherwise.
It's probably not even worth to spend too much time looking at it because some 
details need to be discussed first which might have some deeper impact.
For example, a different approach to handling quirky devices would be to 
implement all device/usb specific things (including initialization etc. which 
is done in main.c) via exchangeable "backends").
After that, I might rip out single chunks of functionality and adapt them to 
separately comprehensible patches...

Best regards,
Sandro