Messages in this thread | | | Date | Tue, 19 Feb 2002 12:52:32 +0100 (MET) | From | "Maciej W. Rozycki" <> | Subject | Re: [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 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/
| |