Re: [RFC][PATCH 00/12] Enhanced file stat system call

[Andreas Dilger]

On Nov 26, 2015, at 8:19 AM, David Howells <dhowells@xxxxxxxxxx> wrote:
> 
> Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> 
>> from a quick look the statx bits looks fine in general.  I think Ted
>> last time had a problem with the IOC flag allocation, so you might
>> want to ping him.
> 
> Yeah - he commented on that.
> 
>> But fsinfo with the multiplexer and the void pointer is just horrible.
>> What were you thinking there?
> 
> I think the fsinfo data struct probably wants splitting up.

Could we separate the statx() and fsinfo() submissions so that this doesn't
block statx() landing indefinitely?  I think people are generally in support
of statx() as it is today, and it's been _sooo_ long in coming that I'd hate
to see it delayed further.  The statx() syscall definitely has value without
fsinfo() to improve the life of network filesystems.

Cheers, Andreas

>  Now this could be
> done in a number of ways, including:
> 
> (1) By adding multiple syscalls (statfsx, fsinfo, netfsinfo, ...) but each
>     one needs a bit in the kernel to handle the basics (path/fd lookup,
>     security check, buffer allocation and freeing, ...) which could all be in
>     common - hence the mux method.
> 
> (2) Adding an argument to the fsinfo syscall since it has at least one
>     syscall argument spare.
> 
> (3) Offloading some of the bits to standardised xattr calls.  The large
>     string fields (domain name, volume name, ...) would seem to be obvious
>     candidates for this.
> 
> Given that the core VFS gets to manage the contents of the buffer, it
> shouldn't be as controversial as pioctl().
> 
> David
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers, Andreas

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail