> the patch for newer kernels, including Linux 2.2, rewritten the code to be
> a lot cleaner and the patch is now much smaller and more reasonable.
...
> The 32-bit UIDs are stored in the reserved area of the inode on
> ext2 filesystems, and at least ufs and nfs also should work successfully
I'd say the ext2 code still needs some cleanup. You are using reserved
fields. If you need the space, PLEASE CHANGE THE NAME. (I think you are
the second person to do this) If I look at the code and see "reserved",
I'm going to think it means exactly that. This is not safe.
I see that you are using the .osd2.linux2.l_i_reserved2 member of the
ext2 inode. Consider the layout already in use by the HURD. It matches
up perfectly with the existing Linux inode, but does not match up with
your new inode. It also already supports 32-bit UIDs.
Here it is:
struct {
__u8 h_i_frag; /* Fragment number */
__u8 h_i_fsize; /* Fragment size */
__u16 h_i_mode_high;
__u16 h_i_uid_high;
__u16 h_i_gid_high;
__u32 h_i_author;
} hurd2;
It would be very good to match up with h_i_uid_high and h_i_gid_high.
Inode space is not to be wasted.
You could clean up the inode quite a bit:
struct ext2_inode {
__u16 i_mode; /* File mode */
__u16 i_uid; /* Low 16 bits of UID */
__u32 i_size; /* Size in bytes */
__u32 i_atime; /* Access time */
__u32 i_ctime; /* Creation time */
__u32 i_mtime; /* Modification time */
__u32 i_dtime; /* Deletion Time */
__u16 i_gid; /* Low 16 bits of GID */
__u16 i_links_count; /* Links count */
__u32 i_blocks; /* Blocks count */
__u32 i_flags; /* File flags */
__u32 i_translator; /* HURD only */
__u32 i_block[EXT2_N_BLOCKS];/* Pointers to blocks */
__u32 i_version; /* File version (for NFS) */
__u32 i_file_acl; /* File ACL */
union {
__u32 i_size_high; /* High 32 bits of file size */
__u32 i_dir_acl; /* Directory ACL */
}u;
__u32 i_reserved1;
__u16 i_reserved2;
__u16 i_mode_high; /* HURD only */
__u16 i_uid_high; /* High 16 bits of UID */
__u16 i_gid_high; /* High 16 bits of GID */
__u32 i_author; /* HURD only */
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/