From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755261AbcAOUVe (ORCPT ); Fri, 15 Jan 2016 15:21:34 -0500 Received: from kanga.kvack.org ([205.233.56.17]:53840 "EHLO kanga.kvack.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754481AbcAOUVc (ORCPT ); Fri, 15 Jan 2016 15:21:32 -0500 Date: Fri, 15 Jan 2016 15:21:31 -0500 From: Benjamin LaHaise To: Linus Torvalds Cc: Dave Chinner , linux-aio@kvack.org, linux-fsdevel , Linux Kernel Mailing List , Linux API , linux-mm , Alexander Viro , Andrew Morton 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: User-Agent: Mutt/1.4.2.2i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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." From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 15 Jan 2016 15:21:31 -0500 From: Benjamin LaHaise To: Linus Torvalds Cc: Dave Chinner , linux-aio@kvack.org, linux-fsdevel , Linux Kernel Mailing List , Linux API , linux-mm , Alexander Viro , Andrew Morton 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: 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 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."