We're going to clean the statlite() call up based on this (and
subsequent) discussion and post again.
Thanks!
Rob
Ulrich Drepper wrote:
Christoph Hellwig wrote:
Ulrich, this in reply to these API proposals:
I know the documents. The HECWG was actually supposed to submit an
actual draft to the OpenGroup-internal working group but I haven't seen
anything yet. I'm not opposed to getting real-world experience first.
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?
I don't think an accuracy flag is useful at all. Programs don't want to
use fuzzy information. If you want a fast 'ls -l' then add a mode which
doesn't print the fields which are not provided. Don't provide outdated
information. Similarly for other programs.
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.
Yes, this is also my pet peeve with this interface. I don't want to
have another data structure. Especially since programs might want to
store the value in places where normal stat results are returned.
And also yes on 'statat'. I strongly suggest to define only a statat
variant. In the standards group I'll vehemently oppose the introduction
of yet another superfluous non-*at interface.
As for reusing the existing statat interface and magically add another
parameter through ellipsis: no. We need to become more type-safe. The
userlevel interface needs to be a new one. For the system call there is
no such restriction. We can indeed extend the existing syscall. We
have appropriate checks for the validity of the flags parameter in place
which make such calls backward compatible.
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.
I don't like that approach. The flag parameter should be exclusively an
output parameter. By default the kernel should fill in all the fields
it has access to. If access is not easily possible then set the bit and
clear the field. There are of course certain fields which always should
be added. In the proposed man page these are already identified (i.e.,
those before the st_litemask member).
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.
-
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
