Re: Subject: [PATCH 01/16] Squashfs: inode operations
On Fri, 2008-10-17 at 18:53 +0200, Jörn Engel wrote: None of the comments below are a reason against mainline inclusion, imo. They should get handled, but whether that happens before or after a merge doesn't really matter. On Fri, 17 October 2008 16:42:50 +0100, Phillip Lougher wrote: +#include linux/squashfs_fs.h +#include linux/squashfs_fs_sb.h +#include linux/squashfs_fs_i.h Current verdict seems to be that these files should live in fs/squashfs/, not include/linux/. No kernel code beside squashfs needs the headers and userspace tools should have a private copy. [Snip] I looked at where filesystems such as ext3 store these and it seems to be in include/linux. I'm assuming this is because usespace utilities like fsck need them. It seems wrong for userspace tools to have their own private copy since you can potentially have them out of sync with the kernel you are running and it provides more chance for you forgetting to update a structure somewhere. Dave -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH 12/16] Squashfs: header files
On Fri, 2008-10-17 at 16:42 +0100, Phillip Lougher wrote:
[snip]
+
+struct squashfs_reg_inode {
+ __le16 inode_type;
+ __le16 mode;
+ __le16 uid;
+ __le16 guid;
+ __le32 mtime;
+ __le32 inode_number;
+ __le32 start_block;
+ __le32 fragment;
+ __le32 offset;
+ __le32 file_size;
+ __le16 block_list[0];
+};
+
+struct squashfs_lreg_inode {
+ __le16 inode_type;
+ __le16 mode;
+ __le16 uid;
+ __le16 guid;
+ __le32 mtime;
+ __le32 inode_number;
+ __le64 start_block;
+ __le64 file_size;
+ __le64 sparse;
+ __le32 nlink;
+ __le32 fragment;
+ __le32 offset;
+ __le32 xattr;
+ __le16 block_list[0];
+};
+
+struct squashfs_dir_inode {
+ __le16 inode_type;
+ __le16 mode;
+ __le16 uid;
+ __le16 guid;
+ __le32 mtime;
+ __le32 inode_number;
+ __le32 start_block;
+ __le32 nlink;
+ __le16 file_size;
+ __le16 offset;
+ __le32 parent_inode;
+};
+
+struct squashfs_ldir_inode {
+ __le16 inode_type;
+ __le16 mode;
+ __le16 uid;
+ __le16 guid;
+ __le32 mtime;
+ __le32 inode_number;
+ __le32 nlink;
+ __le32 file_size;
+ __le32 start_block;
+ __le32 parent_inode;
+ __le16 i_count;
+ __le16 offset;
+ struct squashfs_dir_index index[0];
+};
+
[snip]
Something that seems weird is the inconsistency in the ordering of these
structs. The base part is the same across all inodes but for your
reg/lreg dir/ldir pairs you seem to shuffle the order of the added
parts. Is there a reason for this? Is their layout the same on disk
(baring the extra data in the l versions)? If so they probably should be
the same in the struct.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem
On Wed, 2008-10-22 at 00:42 +0100, Phillip Lougher wrote: David P. Quigley wrote: Looking through the code I noticed that you give certain object types the same inode number for all instances of it (devices, fifo/sockets). How is this done internally? Do these types of objects occupy the same position on the inode table? If so how do you differentiate between a device and a socket? No, devices and fifo/sockets get their own unique inode numbers: [EMAIL PROTECTED]:/mnt# mount -t squashfs test.sqsh /mnt2 -o loop [EMAIL PROTECTED]:/mnt# ls -li /mnt2 total 0 2 crw-r--r-- 1 root root 1, 1 2008-10-22 00:31 device 4 prw-r--r-- 1 root root0 2008-10-22 00:31 fifo 3 srwxr-xr-x 1 root root0 2008-10-17 16:25 socket [Snip] My mistake I misread your statement in email 0. You said that squashfs has real inode numbers and that cramfs didn't. Good luck with your mainlining attempt. Once you get xattr support this would definitely make life better for people who want to make SELinux enabled LiveCDs and other small devices. Dave -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem
Looking through the code I see two references to xattrs, one is the index of the xattr table in the superblock and there seems to be struct member in one of the inode structures that is an index into this table. Looking through the code I don't see either of these used at all. Do you intend to add xattr support at some point? I saw reference to the desire to add xattr support in an email from 2004 but you said that the code has been rewritten since then. If you are going to add xattr support you probably want to add it to more than just regular files. In SELinux and other LSMs symlinks and directories are also labeled so they will need xattr entries. Dave -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
