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
