[U-Boot] [PATCH 0/2] New abstraction layer for handling MMC and FAT commands

[Lukasz Majewski]

Dear Marek Vasut,

> Dear Wolfgang Denk,
> 
> > Dear Lukasz Majewski,
> > 
> > In message <20120727123832.69195dcd at amdc308.digital.local> you
> > wrote:
> > > > Sorry if I don't understand, but what exactly is special with
> > > > MMC and FAT here?
> > > 
> > > Those patches are a follow up of a discussion about DFU support in
> > > u-boot.
> > > "[PATCH 4/7] dfu: MMC specific routines for DFU operation"
> > 
> > OK, I see.   Guess I will have to start reading these patches then
> > (which I didn't so far).
> > 
> > > In short - during this discussion it has been suggested, that
> > > sprintf() + run_command() call shall be replaced with a "_safe"
> > > function call, which decouples "real" e.g. MMC write from parsing
> > > user data from prompt.
> > 
> > ...
> > 
> > > I need the FAT and MMC for DFU patches, on which I work now. Those
> > > patches (actually v2) have already been posted to ML and are under
> > > review.
> > 
> > This makes no sense to me.  MMC is just one of the storagte devices
> > we support, and especially with the upcoming support of a clean
> > device model it makes no sense to handle it special in any way.
> 
> Sure, but that might still be a release or so away. So let's not
> hinder people from doing so, rather let's coordinate. Also, I
> consider there patches helpful, as we can use that abstraction during
> the DM work.
> 
> > The same holds for FAT - it is just one out of a number of file
> > systems we support, and it makes no sense to add any code to FAT
> > support that makes it incompatible with other file systems.
> 
> It's not incompatible, how?
> 
> > Any such addition should be implemented in a generic way, that is
> > agnostic of the underlying storage device and the file system used
> > on top of it.
> 
> Should, that's the proper word here. It isn't in most of FSs in uboot
> though and I think this is better than nothing.
> 
> > It is OK if you then test with one combination only, but the
> > implementation shall be generic.
> 
> I still consider it better than nothing -- if we have to pick this up
> and tear it apart during the DM, it's also OK, because we will easily
> figure out what parts to put where. So I'm quite fine with these
> patches.

Nice to hear. 
Anyway I think, that we shall wait for Wolfgang's opinion.


-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group