[PATCH 0/5] PMFS: Rebase to Linux 3.9

[Vishal Verma]

Agree with Ross' and Matthew's comments.
Using the new interfaces for reading/writing [gu]ids.
In addition to the discussion here, I had to make additional changes:

change types of pmfs_sb_info->[gu]id from [gu]id_t to k[gu]id_t
 - doing this breaks various other places where the sbi->[gu]id are
written/read.
 - use these as reference for changing above instances:
  - For writing: 
    -http://lxr.free-electrons.com/source/fs/jfs/super.c?v=3.3#L324 
    +http://lxr.free-electrons.com/source/fs/jfs/super.c#L336
  - For reading:
    -http://lxr.free-electrons.com/source/fs/jfs/super.c?v=3.3#L616
    +http://lxr.free-electrons.com/source/fs/jfs/super.c#L668


Thanks,
-Vishal

On Mon, 2013-04-29 at 13:56 -0600, Ross Zwisler wrote:
> > I think these build errors were caused because kuid_t and kgid_t are now structs:
> > 
> > typedef struct {
> > 	uid_t val;
> > } kuid_t;
> > 
> > 
> > typedef struct {
> > 	gid_t val;
> > } kgid_t;
> 
> Sorry for the running dialog.  :)  I've been looking at this a bit more, and
> it turns out that kuid_t and kgid_t are sometimes structs and sometimes raw
> values, depending on whether CONFIG_UIDGID_STRICT_TYPE_CHECKS is defined.
> 
> It looks like some filesystems handle this by making their internal structures
> also use kuid_t and kgid_t instead of a raw value:
> 
> struct affs_sb_info {
> 	int s_partition_size;		/* Partition size in blocks. */
> 	int s_reserved;			/* Number of reserved blocks. */
> 	//u32 s_blksize;			/* Initial device blksize */
> 	u32 s_data_blksize;		/* size of the data block w/o header */
> 	u32 s_root_block;		/* FFS root block number. */
> 	int s_hashsize;			/* Size of hash table. */
> 	unsigned long s_flags;		/* See below. */
> 	kuid_t s_uid;			/* uid to override */
> 	kgid_t s_gid;			/* gid to override */
> 	...
> 
> So when you do this:
> 	inode->i_uid = sbi->s_uid;
> 
> (inode is of type struct inode*, and sbi is of type struct affs_sb_info*), you
> sometimes are copying a struct, and sometimes copying a single value.
> 
> Another way to deal with this seems to just use i_uid_read(inode) type wrapper
> functions.  Reiserfs seems to go this route.
> 
> For us, since we probably want to keep our struct pmfs_inode in on disk/in
> memory format as __le32, we should probably just use i_uid_read() type
> wrappers?
> 
> Thoughts?
> 
> - Ross
> 
>