> 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 should have added the disclaimer to my original announcement:
"This is for people who do not mind having to backup, reformat, and
restore their ext2 filesystems when the next version of ext2 comes out".
No, I don't intend my patch as a suggestion for how ext2 should be done in
the future. I'll change the name of the fields from 'reserved' to 'uid32'
and 'gid32', respectively- thanks for the advice.
> 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.
>
> 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.
I'm assuming that ext2 will be officially changed to solve this problem in
one way or another in the future. My patch wastes that extra 32 bits of
space, but makes it possible to interchange ext2 filesystems with high
UIDs between normal and 32-bit UID kernels with as few problems as
possible. (my patch is intended for people that need to use 32-bit UIDs on
Linux NOW) If a UID > 65535 exists on the filesystem, an unpatched kernel
will just see it as 65534, just as old binaries see uids/gids >65535 as
65534 in system calls.
-Chris Wing
wingc@engin.umich.edu
-
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/