[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Sunday, 17. February 2002 10:51, David Woodhouse wrote:
> gleixner@xxxxxxx.de said:
> > I implemented a new structure into nand_chip structure, which
> > describes the  usage of the oob area. You can read and modify this
> > structure from the  filesystem driver via two functions, which i have
> > implemented into the mtd  structure. (get_oobcfg, set_oobcfg).
> I'm slightly concerned that this may be overkill. The JFFS2 code has to
> recognise certain types of hardware and arrange its own data in the spare
> area accordingly. Does it really need to make that information available,
> or just do its own thing? Is the existing mtd->{oobblock,oobsize,ecctype}
> really not sufficient?
No. Both the chip layer e.g. NAND, DOC, or something else and every 
filesystem layer has to know about the arrangement of the oob data. Maybe we 
could reduce the information to a filesystem type and define the oob-layout 
as constants in a .h file. That would be less overhead but gives the 
flexibility for both chip and filesystem driver to use free oob layouts.
It would be not a big hack to rearrange it that way.

> OK, let's work on getting your current changes merged, then we can deal
> with the wbuf_flush failure handling. Can you send me a patch against the
> current CVS tree -- I don't think I've changed anything on the
> jffs2-nand-branch recently (since the 5th of February in fact).
Comes along, if we have fixed above question.
Thomas Gleixner, autronix automation GmbH
auf dem berg 3, d-88690 uhldingen-muehlhofen
fon: +49 7556 919891 , fax: +49 7556 919886
mail: gleixner@xxxxxxx.de">http://www.autronix.de  

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com