[U-Boot] [PATCH v2 4/7] dfu: MMC specific routines for DFU operation

[Wolfgang Denk]

Dear Marek Vasut,

In message <201207271443.45189.marex at denx.de> you wrote:
>
> > For this shim layer I would actually prefer the original approach
> > (shown above) to use sprintf() to build commands based on the existing
> > command interface
> 
> We discussed it for a while ... figure out the missing typechecking and abuse of 
> the command line interface is not a way to go.

I agree that this is not the preferred way for a permanent solution,
but for now I cxonsider it acceptable, as it allows to easily deal
with the inconsistent API of the misc file system handlers.  For
example instead of

	sprintf(cmd_buf, "fatread mmc %d:%d 0x%x %s %lx", ...

we can even do something like

	sprintf(cmd_buf, "%s %s  %d:%d 0x%x %s %lx", 
		command, device, ...

and set command as needed to "fatread" or "ext2load" or whatever, and
device can be set to "mmc" or "usb" or ...

> > this is the minimal intrusive way to implement
> > this for now.  With this approach, no modifications to file system
> > and/or device driver code are needed, and we still maintain full
> > flexibility here in the DFU code.  Yes, error checking may not be
> > perfect, and we my not win a price for elegance of design either, but
> > we should get mostly clean, working code quickly.
> 
> But now that we started going in the typechecking way, I'd prefer to go all the 
> way. And once DFU extends properly towards other supported filesystems/devices, 
> the rest of the interface can get cleaned along the way.

You can implement the type checking code when you hav ea stable, well
define API for storage devices and file systems.  For now we don't
have that, and it makes ZERO sense to add special code just for that
just to throw it away in a few weeks.

> Shim layer is cool -- abusing command line is not cool ;-)

Whether this is abuse or clever use remains to be defined, and this
is probably largely a matter of taste.  In any case, this will be a
small piece of code that is of clearly transient nature, to be
replaced or removed as soon as we can do better.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The nice thing about  standards  is that there are  so many to choose
from.                                           - Andrew S. Tanenbaum