[dfu-util] New dfu-suffix manipulation tool
stefan at datenfreihafen.org
Tue Mar 27 17:10:56 CEST 2012
On Sat, 2012-03-24 at 10:41, Tormod Volden wrote:
> On Wed, Mar 7, 2012 at 1:03 PM, Stefan Schmidt wrote:
> >> I will work with Maple to get their firmware compliant, but I would
> >> also like to add quirks to dfu-util so that their already shipped
> >> firmware can work. The extent of the quirk will depend a bit on how we
> >> fix the new Maple firmware. So please hold off the 0.6 release until
> >> we have a confirmed fix. This should give us time to get the suffix
> >> tool right meanwhile :)
> > Sure, I can wait with the 0.6 release for the fix.
> I got a reply from Leaflabs and they were going to test things. But
> since then I haven't heard anything. At the minimum I would like a
> confirmation from them on which USB ID's need to be quirked.
I'm not in a rush with 0.6 here. Still waiting for an unknown time
might also not really help the issue. :)
> >> > For the next release cycle I would like to see how we can integrate
> >> > the windows support Satz Klauer wrote.
> > He sent me his changes as a tarball and I now imported them into a git
> > branch for further work:
> > http://cgit.openezx.org/dfu-util/log/?h=windows
> I had a quick look. It is based off an older tree so we must be
> careful not to revert anything accidentally. But I suppose your plan
> is to introduce the changes piece by piece anyway. Some of the changes
> there make sense in any case, like adding "const" qualifiers. We can
> also port all file handling to use FILE, fread() and friends from
> stdio instead of the less portable read().
Indeed, the plan was picking things piece by piece and keeping the
current state without regressions. My time schedule might get tight
again in the next weeks to months (I'm relocating into another
country) but I still plan to work on this. Once I have split some
things out into smaller changes I will push them to a branch and let
you know for review.
> There were things there I did not like, but we can get back to this
> once we have split up patches for this.
> >> > Values for device, product and vendor id can be in decimal or hex
> >> > notation. Later needs a 0x prefix.
> >> USB tools like lsusb (and dfu-util :) ) always treat product and
> >> vendor IDs as hexadecimal, with or without 0x. Would anyone ever like
> >> to use such an ID in decimal?
Heh, maybe not, but who knows? :)
> >> It could even be an idea to use the same syntax as the -d option of dfu-util.
I dislike this syntax of squeezing both vendor and product IDs into
one string. Here it would be even a third ID with the device ID. I
prefer to keep them separate here.
> > Well with strtol we get thze correct handling for either decimal or
> > hex for free. The downside is that we must use the 0x prefix for
> > correct detection of hex values.
> > I'm not bound to this, but I like the idea to support both notation
> > easily.
> These are IDs and not numbers or addresses. So adding the possibility
> to enter these values in decimal is only confusing. Other tools like
> lsusb and dfu-util always expect the hex codes, which you also find in
> all pci.ids lists or even Windows .inf files.
OK, you won. I will move it back to accept the ID as hex without 0x
prefix. Still I will keep them as three distinct arguments.
> >> This reminds me of one thing I am plentiful guilty of myself in the
> >> dfu-util code: The variable name "file" is poorly chosen, and is
> >> confusingly sometimes used for the structure, sometimes for a pointer
> >> to it. "file" is not a reserved name in C, but it is very generic name
> >> and close to "FILE" from stdio.h, so we should show some better
> >> imagination and use more descriptive name (of course here we always
> >> have only one file so it can not be misunderstood, but the day we add
> >> a second file to the code...).
> > And there we have it again. Engineers are bad at choosing variable
> > names. :)
> > What options do we have for it?
> > The term firmware is used in the specs, but I find it long to write
> > and fw not meaningful enough as abbreviation. Other then that I only
> > can think of dfu_fw or dfu_file also for the variable name. Any good
> > idea?
> I think "firmware" is a bit better than "file". Even if the part of
> the file that we manipulate is the part that is not the actual
> firmware :) It is really a "dfu_file" but we use that for the struct
> so it would also be confusing.
Hmm, firmware is still bothering. Not much better then file imho to
just change it everywhere.
> > I did all changes based on your review in one commit:
> > http://cgit.openezx.org/dfu-util/commit/?h=dfu-suffix
> I think you should rebase/squash the commits there before you pull
> this into master.
Sure, that was the plan. Are you happy with the changes as is? If yes
I will push them into master after squashing and rebasing. The change
for the ID format will go in before obviously.
More information about the devel