From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: linux-nfs-owner@vger.kernel.org Received: from mail-ve0-f173.google.com ([209.85.128.173]:60267 "EHLO mail-ve0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753533Ab3KMRCU (ORCPT ); Wed, 13 Nov 2013 12:02:20 -0500 Received: by mail-ve0-f173.google.com with SMTP id c14so530288vea.32 for ; Wed, 13 Nov 2013 09:02:19 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20131113164959.GL28033@fieldses.org> References: <1384283048-7699-1-git-send-email-bjschuma@netapp.com> <20131112194529.GA26341@fieldses.org> <52828767.3030909@netapp.com> <20131112195911.GA28033@fieldses.org> <5283A24D.4010309@netapp.com> <5283A3B7.8080405@netapp.com> <20131113161527.GA10046@infradead.org> <20131113164959.GL28033@fieldses.org> Date: Wed, 13 Nov 2013 18:02:19 +0100 Message-ID: Subject: Re: [PATCH v2 0/3] NFSD: Implement SEEK From: Joshuah Hurst To: "J. Bruce Fields" Cc: Christoph Hellwig , Anna Schumaker , linux-nfs@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-nfs-owner@vger.kernel.org List-ID: On Wed, Nov 13, 2013 at 5:49 PM, J. Bruce Fields wrote: > On Wed, Nov 13, 2013 at 08:15:27AM -0800, Christoph Hellwig wrote: >> On Wed, Nov 13, 2013 at 11:07:19AM -0500, Anna Schumaker wrote: >> > I'm thinking something like this: >> >> Given that the whole sparse file support seems more experimental than >> the security labels requiring the former for the latter seems a bit odd. >> >> I have to admit that I don't really know how to deal with those changes, >> on the one hand I'd love to expose it as soon as possible, on the other >> hand the spec has so many higher level flaws related to their concepts >> of sparse files that I'd feel really bad about locking even parts of it >> in at the moment. > > This isn't a candidate for 3.13, and SEEK didn't look like the most > problematic bit, so with a couple more months I'm hoping we'll be more > confident about the protocol? > > Actually now that I look, I forget: even if security labels are built > in, 4.2 is still off by default at runtime for now. > > We could add another interface to toggle individual features at run time > but I think that's definitely too complicated. > > Maybe: > > - keep 4.2 off by default a runtime for now. > - keep each feature under its individual config option: > NFSD_V4_SECURITY_LABEL, NFSD_V4_SEEK, NFSD_V4_SEND_PONIES.... > - when an individual feature matures, ditch its config option > and build it unconditionally. We're always getting little > build bugs due to untested build options so I'd rather not > keep them around indefinitely. > - once 4.2 has at least one feature that we think is mature > enough, switch the runtime 4.2 default to on and depend on > scary warnings on the remaining build options to keep people > from exposing them in production. NFSD_V4_SEND_PONIES is mandatory for 3.13!!!!! :) Josh