
Dear Wolfgang Denk,
Dear Marek Vasut,
In message 201207271443.45189.marex@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