Andreas Dilger wrote: > > > Instead, as was proposed in the last generation of this thread, > > > there should be > > > AT_GET_{ATIME,MTIME,CTIME,BLOCKS,SIZE,NLINKS,...}, to return the > > > flags that the application actually wants. > > > > Well, I respectfully disagree. In my opinion, this adds unncessary > > complexity to an already targetted case, where only a handful of > > file systems will even care to optimize away a couple of > > fields. In that light, I really think we want simplicity here. > > The difficult part is that the application knows which fields it is going > to use, and the filesystem knows which fields are expensive to fill in, > and by merging multiple fields together you are deciding arbitrarily that > you know better than either. The main users will be common tools like > "ls --color" and "find", and they know exactly which fields are needed, > but they need to do a LOT of stats so making it efficient is worthwhile. I agree with Andreas. The issue isn't "what is efficient and simple (now)", but what makes a good future-compatible interface. > > The good news is that we still have a > > very good amount of space in the flags field. We could always go back if we > > _really_ find the need to micro-optimize to the point of per stat field > > flags. Again though, at this point I don't really think starting out with a > > slew of flags is a good idea. > > Similar to the helper macros for S_IRWXU = (S_IRUSR|S_IWUSR|S_IXUSR) > applications won't necessarily need to specify all flags explicitly. Yes. If it's intended to re-use the fstatat system call for this, the conversion from "no stat field flags" to AT_STAT_ALL should be done in the general fstatat code. fstatat() is for doing stat() or lstat() relative to an open directory. (Anyone else thing the name is stupid - why isn't it statat like openat, etc.?) So how do you do a selective fstat() - attributes of an open file? Don't waste a flag, and just specify AT_SELF as the pathname value to mean return the attributes of the fd argument itself. AT_SELF would be NULL, or perhaps (const char *) -1 to catch application errors. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html