From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 15 Jan 2016 15:21:31 -0500 From: Benjamin LaHaise Subject: Re: [PATCH 07/13] aio: enabled thread based async fsync Message-ID: <20160115202131.GH6330@kvack.org> References: <80934665e0dd2360e2583522c7c7569e5a92be0e.1452549431.git.bcrl@kvack.org> <20160112011128.GC6033@dastard> <20160112022548.GD6033@dastard> <20160112033708.GE6033@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: Dave Chinner , linux-aio@kvack.org, linux-fsdevel , Linux Kernel Mailing List , Linux API , linux-mm , Alexander Viro , Andrew Morton On Mon, Jan 11, 2016 at 08:48:23PM -0800, Linus Torvalds wrote: > On Mon, Jan 11, 2016 at 8:03 PM, Linus Torvalds > wrote: > > > > So my argument is really that I think it would be better to at least > > look into maybe creating something less crapulent, and striving to > > make it easy to make the old legacy interfaces be just wrappers around > > a more capable model. > > Hmm. Thinking more about this makes me worry about all the system call > versioning and extra work done by libc. > > At least glibc has traditionally decided to munge and extend on kernel > system call interfaces, to the point where even fairly core data > structures (like "struct stat") may not always look the same to the > kernel as they do to user space. > > So with that worry, I have to admit that maybe a limited interface - > rather than allowing arbitrary generic async system calls - might have > advantages. Less room for mismatches. > > I'll have to think about this some more. Any further thoughts on this after a few days worth of pondering? -ben > Linus -- "Thought is the essence of where you are now." -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org