Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755664AbYG3Tpl (ORCPT ); Wed, 30 Jul 2008 15:45:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753646AbYG3TpW (ORCPT ); Wed, 30 Jul 2008 15:45:22 -0400 Received: from brick.kernel.dk ([87.55.233.238]:13290 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754025AbYG3TpT (ORCPT ); Wed, 30 Jul 2008 15:45:19 -0400 Date: Wed, 30 Jul 2008 21:45:16 +0200 From: Jens Axboe To: Miklos Szeredi Cc: torvalds@linux-foundation.org, akpm@linux-foundation.org, nickpiggin@yahoo.com.au, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [patch v3] splice: fix race with page invalidation Message-ID: <20080730194516.GO20055@kernel.dk> References: <20080730175406.GN20055@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1698 Lines: 36 On Wed, Jul 30 2008, Miklos Szeredi wrote: > > On Wed, 30 Jul 2008, Jens Axboe wrote: > > > You snipped the part where Linus objected to dismissing the async > > > nature, I fully agree with that part. > > And also note in what Nick said in the referenced mail: it would be > nice if someone actually _cared_ about the async nature. The fact > that it has been broken from the start, and nobody noticed is a strong > hint that currently there isn't anybody who does. That's largely due to the (still) lack of direct splice users. It's a clear part of the design and benefit of using splice. I very much care about this, and as soon as there are available cycles for this, I'll get it into better shape in this respect. Taking a step backwards is not the right way forward, imho. > Maybe fuse will be the first one to actually care, and then I'll > bother with putting a lot of effort into it. But until someone cares, > nobody will bother, and that's how it should be. That's very much in > line with the evoultionary nature of kernel developments: unused > features will just get broken and eventually removed. People always say then, and the end result is it never gets done. Not to point the finger at Nick, but removing the steal part of the splice design was something I objected to a lot. Yet it was acked on the premise that it would eventually get resubmitted in a fixed manner, but were are not further along that path. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/