Hello, The attached patch provids XATTR support in JFFS2. We can apply it to mtd-snapshot-20050822.tar.bz2 tree. I hope your worthwhile comments for improvement. # By coincidence, two patches for similar functionality are posted in same day :) # I changed the subject of this mail a bit to avoid confusion. This implementation added two new node types JFFS2_NODETYPE_XATTR and JFFS2_NODETYPE_XREF. JFFS2_NODETYPE_XATTR node has a set of XATTR entry which contains name and value. It's represented as jffs2_raw_xattr structure on MTD-device. JFFS2_NODETYPE_XREF node has a set of reference to associate inode with XATTR. It's represented as jffs2_raw_xref structure on MTD-device. * Data Structure - jffs2_xattr_cache This object contains XATTR name/value. It must be refered by an inode at least. When the last inode which refers jffs2_xattr_cache is unlinked, jffs2_xattr_cache will be deleted. XATTR name/value is not loaded until inode object is allocated. - jffs2_xattr_ref This object refers jffs2_inode_cache and jffs2_xattr_cache, and chains each other. When we walk on ref->ilist from jffs2_inode_cache, we can scan all the XATTR which is bound to this inode. Adversely, we can scan all the inode which refers this XATTR, when we walk on ref->xlist from jffs2_xattr_cache. struct jffs2_xattr_cache { struct list_head xcache; <-- It's chained from struct jffs2_sb_info (global hash list). struct list_head xlist; <-- jffs2_xattr_ref is chained on this list. struct jffs2_raw_node_ref *node; uint32_t xid; <-- Unique Identifier uint32_t version; uint32_t crc; char *xname; /* XATTR name */ <-- char *xvalue; /* XATTR value */ int xsize; /* size of XATTR value */ }; struct jffs2_xattr_ref { uint32_t seqno; /* sequencial number */ uint32_t flags; struct list_head ilist; /* list from jffs2_inode_cache */ struct list_head xlist; /* list from jffs2_xattr_cache */ struct jffs2_xattr_cache *xc; struct jffs2_inode_cache *ic; struct jffs2_raw_node_ref *node; }; * How to work [1] FS mounting When jffs2 is mounting, xattrcache which is array of list_head is created by kmalloc() on jffs2_sb_info first. Then jffs2_scan_eraseblock() is called on each erase block, and jffs2_scan_xattr_node() and jffs2_scan_xref_node() are used to treat two new node-type. jffs2_scan_xattr_node() create jffs2_xattr_cache object and chain it to xattrcache. jffs2_scan_xref_node() create jffs2_xattr_ref object and chain it to temporary list. Next, jffs2_build_xattr_caches() is called. This function associate jffs2_inode_cache with jffs2_xattr_cache by using jffs2_xattr_ref. (struct jffs2_xattr_ref *)ref->ilist ... Chained jffs2_inode_cache (struct jffs2_xattr_ref *)ref->xlist ... Chained jffs2_xattr_cache [2] inode-creation When inode object is created, jffs2_get_xattr_inode() will be called. It walks on ilist on inode-cache and calls do_load_xattr_cache() for related XATTR object to load XATTR name/value. [3] getxattr/setxattr We can refer an jffs2_inode_cache object in {get|set}xattr handler, and walks on jffs2_inode_cache->ilist for looking up target XATTR. In setxattr case, do_create_xattr_cache() is called for creation new XATTR-node, then do_delete_xattr_ref() is used for old-node. * Example of use [root@saba ~]# dd if=jffs2.xattr.img of=/dev/mtdblock0 8192+0 records in 8192+0 records out [root@saba ~]# mount -t jffs2 /dev/mtdblock0 /mnt/0 [root@saba ~]# ls -lZ /mnt/0 drwxr-xr-x root root system_u:object_r:bin_t bin/ drwxr-xr-x root root system_u:object_r:mnt_t dev/ drwxr-xr-x root root system_u:object_r:etc_t etc/ -rw-r--r-- root root system_u:object_r:mnt_t hoge -rwxr-xr-x root root system_u:object_r:mnt_t init* drwxr-xr-x root root system_u:object_r:lib_t lib/ drwxr-xr-x root root system_u:object_r:mnt_t loopfs/ drwxr-xr-x root root system_u:object_r:mnt_t proc/ lrwxrwxrwx root root system_u:object_r:bin_t sbin drwxr-xr-x root root system_u:object_r:mnt_t sys/ drwxr-xr-x root root system_u:object_r:mnt_t sysroot/ [root@saba ~]# * ToDo List (1) stabilization o more tests and debugging are necessary. I hope any trouble reporting. I don't have real MTD device. This implementation is developed on MTD-RAM pseudo device. Does it work on real MTD-devices ? (2) performance & scalability o Currently, any XATTR objects are guarded by a xattr_sem. But this implementation is not scale, I guess. To divid locking is necessary. o When setxattr() is called, the system scans XATTR cache to look for same combination of name/value and share it. But it's so expensive process, to reduce finding-step is necessary. (3) more functionality o Currently, only XATTR has "security.*" prefix is supported. It's enough to use SELinux, but that's more useful if we can use POSIX-ACL and so on. o modifying mkfs.jffs2 command. Thanks, -- Linux Promotion Center, NEC KaiGai Kohei