[RFC][PATCH 00/12] Enhanced file stat system call
adilger at dilger.ca
Thu Nov 26 22:06:19 UTC 2015
On Nov 26, 2015, at 8:19 AM, David Howells <dhowells at redhat.com> wrote:
> Christoph Hellwig <hch at infradead.org> 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.
> 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().
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the samba-technical