NAND ECC Layout, sysfs question

* NAND ECC Layout, sysfs question
@ 2010-08-05 17:53 Brian Norris
  2010-08-05 18:18 ` Artem Bityutskiy
  0 siblings, 1 reply; 40+ messages in thread
From: Brian Norris @ 2010-08-05 17:53 UTC (permalink / raw)
  To: linux-mtd

Hello,

I'm trying to replace the following structure (in mtd-abi.h) and its 
corresponding ioctl with a larger, dynamic form exported via sysfs. 
We're running out of room in the eccpos and oobfree arrays on larger chips:

#define MTD_MAX_OOBFREE_ENTRIES 8
/*
  * ECC layout control structure. Exported to userspace for
  * diagnosis and to allow creation of raw images
  */

struct nand_ecclayout {
         __u32 eccbytes;
         __u32 eccpos[64];
         __u32 oobavail;
         struct nand_oobfree oobfree[MTD_MAX_OOBFREE_ENTRIES];
};

First, is it a smart idea to use sysfs?

Second, if we go with sysfs, there seem to be many potential ways to 
structure the "eccpos" and "oobfree" arrays. Bearing in mind the 
convention of either one entry per file or a space-separated array of 
values as well as the file limit of PAGE_SIZE (approx. 4096 bytes?), 
there are several options with which I'm having difficulty. Formats 
could be as follows:
1) Single file: 0 1 2 3 6 7 10 12
2) Single file: 0-3 6-7 10 12
3) Multiple files:
     file 0: 0 3
     file 1: 6 7
     file 2: 10 10
     file 3: 12 12
It seemed to me like (3) was the cleanest while ensuring we fit under 
PAGE_SIZE even if the OOB gets to be 1000+ bytes, so no one ever has to 
come back and redo this :) Unfortunately, directories and a dynamic 
number of attributes/files aren't really straightforward, hence my next 
questions...

Third, if I were to create directories under the "mtdX" sysfs directory, 
what's the best way to do this? Explicitly creating and filling in a 
kobject? Or creating a new "device"? Or are there other, better options?

I've already coded parts of a few of these options, but they all have 
various difficulties and can easily become ugly pieces of code (at least 
with my limited skill at sysfs).

Thanks,
Brian

^ permalink raw reply	[flat|nested] 40+ messages in thread