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

[Marek Vasut]

Dear 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 ...

Given that they have slightly different syntax, this is crazy too.

> > > 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.

Ad API -- adding Pavel to CC. Hope his GMail works better than mine (mine 
doesn't, crashed again, damned google stuff). Pavel, can you provide us with how 
the API will look maybe?

> > 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

Well ... after this discussion, I feel like I'll just go dig me a grave again.

Best regards,
Marek Vasut