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

Lukasz Majewski l.majewski at samsung.com
Fri Jul 27 12:38:32 CEST 2012


Dear Wolfgang Denk,

> Dear Lukasz Majewski,
> 
> In message <1343378116-5569-1-git-send-email-l.majewski at samsung.com>
> you wrote:
> > New abstraction layer for performing MMC and FAT operations has
> > been added. It is necessary for using MMC and FAT operations from
> > other subsystems without the need to call "sprintf" and
> > "run_command" afterwards.
> > 
> > MMC/FAT function call allows for better type checking during
> > compilation time. For FAT, common code has been encapsulated to a
> > separate function.
> > 
> > Lukasz Majewski (2):
> >   mmc: New abstract function (do_mmcops_safe) for MMC subsystem
> >   fat: New abstract function (do_fat_safe) for FAT subsystem
> 
> 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"

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/134401/match=dfu+mmc+specific+routines+dfu+operation

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. 

> 
> Why are the same changes as to the MMC code not also needed for
> example for the IDE, SATA, SCSI or USB code?

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.


> 
> Why are the same changes as for FAT not also needed for the other file
> systems?

It is because DFU is not supporting other file systems for now. I only
changed the code which I use.

> 
> 
> And what exactly are you changing anyway?  The commit messages in the
> patches give neither sufficient information to understand why you make
> a change at all, nor how the new code is supposed to be used, nor in
> which way he is better ("more safe" ?) than the existing code?

The problem is as follows:
1. DFU patches requires access to FAT and MMC
2. I'm using sprintf() + run_command() approach to execute e.g. "mmc
write 0x44000000 60 100" to store data from DFU in a proper place.
3. The approach presented at 2. was under discussion on ML. Reviewers
suggested, that run_command() approach is unsafe and for compilation
time type checking I shall write mmc with using special "_safe"
function.

For more details, please visit link, which I've posted. 
In this discussion we are arguing about pros and cons of using sprintf
+ run_command approach.

-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group


More information about the U-Boot mailing list