aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/jffs2.h
Commit message (Collapse)AuthorAge
* [JFFS2][XATTR] using 'delete marker' for xdatum/xref deletionKaiGai Kohei2006-06-27
| | | | | | | | | | | | | | | | | - When xdatum is removed, a new xdatum with 'delete marker' is written. (version==0xffffffff means 'delete marker') - When xref is removed, a new xref with 'delete marker' is written. (odd-numbered xseqno means 'delete marker') - delete_xattr_(datum/xref)_delay() are new deletion functions are added. We can only use them if we can detect the target obsolete xdatum/xref as a orphan or errir one. (e.g when inode deletion, or detecting crc error) [1/3] jffs2-xattr-v6-01-delete_marker.patch Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
* Merge git://git.infradead.org/jffs2-xattr-2.6David Woodhouse2006-05-20
|\ | | | | | | Signed-off-by: David Woodhouse <dwmw2@infradead.org>
| * Merge git://git.infradead.org/mtd-2.6KaiGai Kohei2006-05-18
| |\
| * | [JFFS2][XATTR] XATTR support on JFFS2 (version. 5)KaiGai Kohei2006-05-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This attached patches provide xattr support including POSIX-ACL and SELinux support on JFFS2 (version.5). There are some significant differences from previous version posted at last December. The biggest change is addition of EBS(Erase Block Summary) support. Currently, both kernel and usermode utility (sumtool) can recognize xattr nodes which have JFFS2_NODETYPE_XATTR/_XREF nodetype. In addition, some bugs are fixed. - A potential race condition was fixed. - Unexpected fail when updating a xattr by same name/value pair was fixed. - A bug when removing xattr name/value pair was fixed. The fundamental structures (such as using two new nodetypes and exclusion mechanism by rwsem) are unchanged. But most of implementation were reviewed and updated if necessary. Espacially, we had to change several internal implementations related to load_xattr_datum() to avoid a potential race condition. [1/2] xattr_on_jffs2.kernel.version-5.patch [2/2] xattr_on_jffs2.utils.version-5.patch Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
* | | [JFFS2] Support new device nodesDavid Woodhouse2006-05-18
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | Device node major/minor numbers are just stored in the payload of a single data node. Just extend that to 4 bytes and use new_encode_dev() for it. We only use the 4-byte format if we _need_ to, if !old_valid_dev(foo). This preserves backwards compatibility with older code as much as possible. If we do make devices with major or minor numbers above 255, and then mount the file system with the old code, it'll just read the first two bytes and get the numbers wrong. If it comes to garbage-collect it, it'll then write back those wrong numbers. But that's about the best we can expect. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
* | [JFFS2] Repack some on-medium structures. ARM is weirder than I thought.David Woodhouse2006-05-16
| | | | | | | | | | | | | | | | We have to pack at least the jint16_t structure, because otherwise it'll be four bytes in size. Thankfully, we can do that and _not_ pack the actual node structures, and the compiler still doesn't emit stupid code. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
* | [JFFS2] Don't pack on-medium structures, because GCC emits crappy codeDavid Woodhouse2006-05-14
|/ | | | | | | | | | | | | | | | If we use __attribute__((packed)), GCC will _also_ assume that the structures aren't sensibly aligned, and it'll emit code to cope with that instead of straight word load/save. This can be _very_ suboptimal on architectures like ARM. Ideally, we want an attribute which just tells GCC not to do any padding, without the alignment side-effects. In the absense of that, we'll just drop the 'packed' attribute and hope that everything stays as it was (which to be fair is fairly much what we expect). And add some paranoia checks in the initialisation code, which should be optimised away completely in the normal case. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
* [JFFS2] Clean up trailing white spacesThomas Gleixner2005-11-07
| | | | Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* [JFFS2] Rename jffs2_summary_node to jffs2_raw_summaryFerenc Havasi2005-11-06
| | | | | Signed-off-by: Ferenc Havasi <havasi@inf.u-szeged.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* [JFFS2] Add erase block summary support (mount time improvement)Ferenc Havasi2005-11-06
| | | | | | | | | | | | | | | | | | The goal of summary is to speed up the mount time. Erase block summary (EBS) stores summary information at the end of every (closed) erase block. It is no longer necessary to scan all nodes separetly (and read all pages of them) just read this "small" summary, where every information is stored which is needed at mount time. This summary information is stored in a JFFS2_FEATURE_RWCOMPAT_DELETE. During the mount process if there is no summary info the orignal scan process will be executed. EBS works with NAND and NOR flashes, too. There is a user space tool called sumtool to generate this summary information for a JFFS2 image. Signed-off-by: Ferenc Havasi <havasi@inf.u-szeged.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* [jffs2] Remove compressor lzo and lzariFerenc Havasi2005-11-06
| | | | | | | Remove unused compressor code Signed-off-by: Ferenc Havasi <havasi@inf.u-szeged.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* [JFFS2] Namespace clean upArtem B. Bityutskiy2005-11-06
| | | | | | | | Rename functions to a name matching the functionality. Remove stall debug code Signed-off-by: Artem B. Bityutskiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-16
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!