On Wed, Mar 03, 2010 at 10:36:21PM +0900, OGAWA Hirofumi wrote:
> > - having the highlevel inode operations duplicated between msdos
> > and vfat is probably a bad idea, and we should only branch out
> > for the very low-level directory entry manipulations.
>
> I know you are finding the reason to merge those. ;)
>
> Well, what code are you suggesting? (BTW, this is not meaning "Please
> send a patch."). Can we do it without the user visible change? And if
> it has the user visible change, what is benefit to users?
>
> I know, if we kill original design decision with the user visible
> change, we can write much more faster/cleaner code. (e.g. some I/O can
> be reduced for directory. etc.) But, for fatfs, I'm thinking there is no
> benefit to take a pain by the user visible change, at least for now.
There's a couple of things I have in mind:
- first move fat and msdos into the same module to make integration
easier. Keep MODULE_ALIASes for vfat and msdos to allow old module
(auto-)load setups working. Move the setup for the two
file_system_type structures to super.c
- look at the spurious differences between namei_msdos.c and
namei_vfat.c. Here's a few I've noticed and I'll have patches for
soon hopefully:
- msdos only updates c and mtime in msdos_add_entry, but vfat
also updates atime
- msdos only updates ctime in rmdir and unlink , vfat otoh only
updates mtime and atime
- vfat updates the ctime on the new inode in rename, msdos
doesn't.
- udate i_version consistently in msdos, too (probably not needed
without nfs exporting, but just to make the code similar)
- unify the vfat_add_entry/msdos_add_entry prototypes and make them
function pointers hanging off the superblock information
- move the hidden file handling and msdos_format_name into a helper
and make that a function pointer hanging off the superblock,
with a no-op implementation for vfat
- unify the prototypes of msdos_find and vfat_find and make it
a function pointer hanging off the superblock
At this point basically all the inode operations are the same for
both and can be merged, spreading out via the three operations
mentioned above. If we don't want the indirection it could also
be done using if/else statements in a small helper. The only one
I haven't analyzed in detail yet is rename, because it looks too
different and will need some refactoring first.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
