Re: [PATCH] mtd/utils: sync with MTD ioctl interface rework to get rid of MEMGETOOBSEL/MEMSETOOBSEL

[Todd Poynor <tpoynor@mvista.com>]

Vitaly Wool wrote:
> Todd Poynor wrote:
...
>>>          if (writeoob) {
>>>              /* Read OOB data from input file, exit on failure */
>>> -            if ((cnt = read(ifd, oobreadbuf, meminfo.oobsize)) != 
>>> meminfo.oobsize) {
>>> +            if ((cnt = read(ifd, oobreadbuf, oobavail)) != oobavail) {
>>
>>
>> This requires the input file to be tailored to the oobavail of a 
>> specific destination device, reducing the benefit of autoplacement.  
>> It may be best to continue to pad input files oob data to the full 
>> oobsize, much like the data portion is handled.
> 
> Well, padding doesn't work in nandwrite if the image to be written 
> contains OOB data. The idea as I see it is if you are trying to write 
> the image with OOB data, you should know what you're doing, and that 
> implies knowledge of the oobavail size.
> On the other hand, it might be useful to implement an option for 
> nandwrite which specifies what OOB data length user supposes (default 
> will be the oobavail).

In order to make it work as above, we'd need a way for users to find out 
what oobavail their mtd driver uses (in dmesg and/or a util), and an 
option on all the fs utils to write that number of bytes.  A file format 
that specifies what data and OOB size have been generated would do the 
trick, if we want to get that fancy about it.  Just filling out all 16 
or 64 bytes in the input file and truncating to oobavail at nandwrite 
time seems a lower-cost workaround.


-- 
Todd