Michael Kerrisk <mtk.manpages@xxxxxxxxx> wrote:
> > struct xstat_parameters {
> > unsigned long long request_mask;
>
> Poor name, since it's a value-result arg? Better maybe something like
> "field_mask"?
No. The contents of xstat_parameters aren't changed. request_mask is what
you're asking for, result_mask in the xstat struct is what you actually got.
result_mask may be more or less than request_mask as the filesystem isn't
obliged to supply anything you didn't ask for, and may not be able to supply
something you did ask for, and may give you stuff anyway that you didn't ask
for if it's trivial to do so.
> There is no XSTAT_REQUEST__GET_ANYWAY, AFAICS. I guess here you meant
> XSTAT_REQUEST__EXTENDED_STATS? Or?
Yep. I forgot to change that in the patch description.
> This case is almost certainly a user error, so why not simply return
> an error (-1 and ERANGE or E2BIG)? The above approach invites
> userspace errors of the form:
>
> if (xtat(...) < 0) { /* How users often check for error */
> /* I'll handle the error */
> } else {
> /* The call succeeded; I'm fine */
> }
I suppose.
> If you are looking for a way to inform the user about the required
> buffer size, I think it would be better to take a leaf from the
> getxattr(2) book: if 'buflen' is zero, then do nothing with the output
> arg, but return the size that would be required.
That's reasonable.
David
--
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
