From: Arnd Bergmann <arnd@arndb.de>
To: Chris Mason <chris.mason@oracle.com>
Subject: Re: Btrfs for mainline
Date: Sun, 4 Jan 2009 22:52:44 +0100
User-Agent: KMail/1.9.9
Cc: Christoph Hellwig <hch@infradead.org>, Matthew Wilcox <matthew@wil.cx>,
       Andi Kleen <andi@firstfloor.org>,
       Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org,
       linux-fsdevel <linux-fsdevel@vger.kernel.org>,
       linux-btrfs <linux-btrfs@vger.kernel.org>
References: <1230722935.4680.5.camel@think.oraclecorp.com> <20090103195034.GA27541@infradead.org> <1231013856.7538.89.camel@think.oraclecorp.com>
In-Reply-To: <1231013856.7538.89.camel@think.oraclecorp.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200901042252.45054.arnd@arndb.de>
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 945
Lines: 24

On Saturday 03 January 2009, Chris Mason wrote:
> 
> > Actually a lot of the ioctl API don't just need documentation but
> > a complete redo. ?That's true at least for the physical device
> > management and subvolume / snaphot ones.
> > 
> 
> The ioctl interface is definitely not finalized. ?Adding more vs
> replacing the existing ones is an open question.

As long as that's an open question, the ioctl interface shouldn't get
merged into the kernel, or should get in as btrfsdev, otherwise you
get stuck with the current ABI forever.

Is it possible to separate out the nonstandard ioctls into a patch
that can get merged when the interface is final, or will that make
btrfs unusable?

	Arnd <><
--
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/