Lately I have been encaged at other activities, and haven't
had time to check upon VFS layer happenings.
On Wed, Feb 09, 2000 at 11:31:03AM -0500, Matthew Wilcox wrote:
> Greetings. Ted Ts'o recently hosted an ext2 puffinfest where we
> discussed the future of the VFS and ext2. Ben LaHaise, Phil Schwan,
...
Add pathconf() to the VFS. Right now the peeks I have had at
2.3 series do show that people do WRONG things with O_LARGEFILE
flag bit per what the LFS semantics are telling.r
The filesystem must be able to pass to the VFS what capabilities
given file/directory has -- like can filesizes exceeding 2G be
used at all... (EXT2, UFS, NFSv3 can, MINIX et.al. can't..)
(And filenamesizes supported at directories, and...)
These don't look right even at egrep tersenes: (2.3.42)
[root@mea linux]# egrep O_LARGEFILE $cc
./fs/open.c: flags |= O_LARGEFILE;
./fs/ext2/file.c: * the caller didn't specify O_LARGEFILE. On 64bit systems we force
./fs/ext2/file.c: if (inode->u.ext2_i.i_high_size && !(filp->f_flags &
O_LARGEFILE))
./fs/udf/file.c: * On 64 bit systems we force on O_LARGEFILE in sys_open.
./fs/udf/file.c: if ((inode->i_size & 0xFFFFFFFF00000000UL) && !(filp->f_flags
& O_LARGEFILE))
./arch/sparc64/kernel/sys_sparc32.c: * not force O_LARGEFILE on.
./arch/sparc64/solaris/fs.c: if (flags & 0x2000) fl |= O_LARGEFILE;
The limit at 32-bit systems is 2G, not 4G, and NO kernel space system
shall (aside of sys_open64() syscall) set that flag. (Which I think
the sparc64/solaris thing does.)
The tests of file open at EXT2 and UDF (?!) should, I think, be
conditionalized under a wrapper of:
#if BITS_PER_LONG == 32
...
#endif
Sigh, so much to do, so little time for kernel hacking...
/Matti Aarnio <[EMAIL PROTECTED]>
