On Jan 11, 2016 8:04 PM, "Linus Torvalds" <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Jan 11, 2016 at 7:37 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > Yes, I heard you the first time, but you haven't acknowledged that > > the aio fsync interface is indeed different because it already > > exists. What's the problem with implementing an AIO call that we've > > advertised as supported for many years now that people are asking us > > to implement it? > > Oh, I don't disagree with that. I think it should be exposed, my point > was that that too was not enough. > > I don't see why you argue. You said "that's not enough". And I jjust > said that your expansion wasn't sufficient either, and that I think we > should strive to expand things even more. > > And preferably not in some ad-hoc manner. Expand it to *everything* we can do. > > > As for a generic async syscall interface, why not just add > > IOCB_CMD_SYSCALL that encodes the syscall number and parameters > > into the iovec structure and let the existing aio subsystem handle > > demultiplexing it and handing them off to threads/workqueues/etc? > > That would likely be the simplest approach, yes. > > There's a few arguments against it, though: > > - doing the indirect system call thing does end up being > architecture-specific, so now you do need the AIO code to call into > some arch wrapper. How many arches *can* do it? As of 4.4, x86_32 can, but x86_64 can't yet. We'd also need a whitelist of acceptable indirect syscalls (e.g. exit is bad). And we have to worry about things that depend on the mm or creds. It would be extra nice if we could avoid switch_mm for things that don't need it (fsync) and only do it for things like read that do. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
