[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878vezq0nn.fsf@devron.myhome.or.jp>
Date: Wed, 04 Jul 2012 19:30:04 +0900
From: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To: "Steven J. Magnani" <steve@...idescorp.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] fat (exportfs): drop ineffective get_parent code
"Steven J. Magnani" <steve@...idescorp.com> writes:
> This patch reorganizes existing code for reuse by the next patch in the series.
Please separate cleanup and logic change. This patch seems to be almost
all changes are cleanup.
Maybe it would be the cleanup and nfs improvement patches.
> The only functional change is to remove ineffective code from
> fat_get_dotdot_entry() and limit fat_get_parent() to immediate children of the
> root (the only disconnected directory case that can be handled without a
> search). The limitation will be removed in the next patch in the series.
>
> These changes are a slight improvement over the current situation, in that they
> allow reconnection of immediate subdirectories of the root, and reporting of
> ESTALE for other cases.
I can't see why we need the limited get_parent(). I guess, it is better
to just do in next patch at once.
> The reason the i_pos code in fat_get_dotdot_entry() is ineffective is
> because the value is the on-disk position of a ".." directory entry.
> What is needed in order to map NFS file handles back to objects is the on-disk
> position of the named entry to which ".." refers.
[...]
> +/**
> + * Create inode from specified directory entry.
> + * Do not call this directly unless intentionally bypassing the FAT dir cache.
> + */
> +static struct inode *fat_build_unhashed_inode(struct super_block *sb,
> + struct msdos_dir_entry *de)
fat_new_inode() would be better name.
--
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists