[lkml]   [2002]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patches] RFC: Export inode generations to the userland
On Tue, 19 Feb 2002, Andreas Dilger wrote:

> Well, I don't see what's so bad with EXT2_IOC_GETVERSION? It's not like
> many Linux filesystems have inode generation numbers in the first place.

1. You need permissions to open a file.

2. Opening may cause undesired side effects (think "/dev/st0").

3. You can't open a symlink.

> It may even be that reiserfs does/would implement the EXT2_IOC_GETVERSION
> ioctl also (they implemented EXT2_IOC_GETATTR compatible with ext2/ext3).
> You can wrap this inside glibc if you really want to, and that has the
> added benefit of working with all kernels in existence. That's not to
> say this ioctl is the best interface...

Due to the limitations quoted above the ioctl is unsuitable as an
underlying way to retrieve "st_gen" for neither of stat(), stat64(),
lstat() or lstat64().

> IIRC, there are several other desirable changes to struct stat/stat64
> (64-bit timestamps, 32-bit UIDs/GIDs, and others I believe, some searching
> should show up complaintants) so if there is really a need to add yet
> _another_ stat struct/syscall we may as well do it right _this_ time
> (like we've said every other time we change this interface).

Fully agreed. It might be desireable to keep a few spare bytes at the
end of the new "struct stat64" as well (like it's already done for "struct
stat"), so there is no need to add syscalls each time a new member is

+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail:, PGP key available +

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [W:0.043 / U:7.316 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site