[dfu-util] New dfu-suffix manipulation tool
lists.tormod at gmail.com
Sat Mar 24 10:41:56 CET 2012
On Wed, Mar 7, 2012 at 1:03 PM, Stefan Schmidt wrote:
> Oh, pity. :(
>> 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.
>> > 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:
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().
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?
>> It could even be an idea to use the same syntax as the -d option of dfu-util.
> 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
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.
>> 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
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.
> I did all changes based on your review in one commit:
I think you should rebase/squash the commits there before you pull
this into master.
More information about the devel