From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin LaHaise Subject: Re: [PATCH 07/13] aio: enabled thread based async fsync Date: Fri, 15 Jan 2016 15:21:31 -0500 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 Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Linus Torvalds Cc: Dave Chinner , linux-aio-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, linux-fsdevel , Linux Kernel Mailing List , Linux API , linux-mm , Alexander Viro , Andrew Morton List-Id: linux-api@vger.kernel.org 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."