Return-Path: MIME-Version: 1.0 In-Reply-To: <20130409003720.GA5145@thunk.org> References: <201304090003.47056.chunkeey@googlemail.com> <20130409003720.GA5145@thunk.org> Date: Mon, 8 Apr 2013 18:51:10 -0700 Message-ID: Subject: Re: Version number policy! From: Adrian Chadd To: "Theodore Ts'o" , Adrian Chadd , Christian Lamparter , Eugene Krasnikov , Kalle Valo , "Luis R. Rodriguez" , linux-bluetooth , linux-wireless , ath9k_htc_fw , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: On 8 April 2013 17:37, Theodore Ts'o wrote: > There shouldn't be any crap; just a an error message indicating that > "the file system has features which this implementation doesn't > understand". At least, if the implementation was competently > coded.... (ext2/3/4 has feature bitmasks that make it very clear what > features are required so that an implementation can mount the file > system read/write or read/only). Right, the design side of it is fine. But then you end up with people making filesystems which aren't necessarily backwards compatible (and aren't aware of this), then try to share with other extX implementations; or boot an older Linux kernel (eg plugging an ext3 device on a newer box to an older box.) Now, ext3 is a bit more mature nowdays so people aren't _always_ hitting this corner case. But I do recall earlier on when things were moving forward quite quickly, people would create drives on Linux machine X that couldn't be read or written to on Linux machine Y. I'm not knocking extX here; I'm just pointing out that exposing things as a set of capability flags doesn't magically fix interoperability. It just stops you from scribbling crap where it shouldn't be. Adrian