I'd like to Cc Ulrich Drepper in this thread because he's going to decide what APIs will be exposed at the C library level in the end, and he also has quite a lot of experience with the various standardization bodies. Ulrich, this in reply to these API proposals: http://www.opengroup.org/platform/hecewg/uploads/40/10903/posix_io_readdir+.pdf http://www.opengroup.org/platform/hecewg/uploads/40/10898/POSIX-stat-manpages.pdf On Tue, Dec 05, 2006 at 03:50:40PM -0600, Rob Ross wrote: > So other than this "lite" version of the readdirplus() call, and this > idea of making the flags indicate validity rather than accuracy, are > there other comments on the directory-related calls? I understand that > they might or might not ever make it in, but assuming they did, what > other changes would you like to see? statlite needs to separate the flag for valid fields from the actual stat structure and reuse the existing stat(64) structure. stat lite needs to at least get a better name, even better be folded into *statat*, either by having a new AT_VALID_MASK flag that enables a new unsigned int valid argument or by folding the valid flags into the AT_ flags. It should also drop the notation of required vs optional field. If a filesystem always always has certain values at hand it can just fill them even if they weren't requested. I think having a stat lite variant is pretty much consensus, we just need to fine tune the actual API - and of course get a reference implementation. So if you want to get this going try to implement it based on http://marc.theaimsgroup.com/?l=linux-fsdevel&m=115487991724607&w=2. Bonus points for actually making use of the flags in some filesystems. Readdir plus is a little more involved. For one thing the actual kernel implementation will be a variant of getdents() call anyway while a readdirplus would only be a library level interface. At the actual C prototype level I would rename d_stat_err to d_stat_errno for consistency and maybe drop the readdirplus() entry point in favour of readdirplus_r only - there is no point in introducing new non-reenetrant APIs today. Also we should not try to put in any of the synchronization or non-caching behaviours mentioned earlier in this thread (they're fortunately not in the pdf mentioned above either). If we ever want to implement these kinds of additional gurantees (which I doubt) that should happen using fadvise calls on the diretory file descriptor. Note that I'm not as sure we really wants this as for the partial stat operation. In doubt get the GFS folks to do the in-kernel infrastructure for their NFS serving needs first and then see what a syscall could help. - 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
