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
added.
-- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Feb 23 2002 - 21:00:19 EST