Re: [PATCH] IFS: Inode FileSystem

Dag-Erling Smørgrav wrote:
> Scott Long <scottl_at_pooker.samsco.org> writes:
> 
>>On Mon, 6 Jun 2005, [iso-8859-1] Dag-Erling Smørgrav wrote:
>>
>>>Changing the stat(2) API to support 64-bit inodes does not require us
>>>to simultaneously change the on-disk layout of every filesystem we
>>>support to use 64-bit inodes.  However, if we want to fully support
>>>filesystems with 64-bit inodes (such as FAT32, which currently uses a
>>>convoluted hack to map the 64-bit offset of a directory entry into a
>>>32-bit inode), we need to change the API.
>>
>>Ah, I see your point.  Well, it's not too late to address this for 6.0,
>>and it might be a really good idea to think about it now.  Is there
>>anything else that should be bumped along with it?
> 
> 
> Not that I know of.
> 
> I believe the best way to do this is the way Linux did it: introduce
> new *stat64() syscalls and keep the old ones around.  #define magic in
> <sys/stat.h> will take care of making *stat64() look like *stat().
> 
> DES

So one of the advantages that we have with the 5.x -> 6.0 migration
right now is that it's still possible to run a 5.x userland with a 6.x
kernel without much problem.  Changing fundamental syscalls and
structures would defeat this and make life much harder for people that
want to sell 6.0 as a painless migration.  On the surface I like your
idea of stat64 (regardless of politics of having 64-bit specific in the
API names), but I'd like to think on it a bit.  In the mean time I'm off
to listen to Steve profess his love to Intel ;-)

Scott