From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrian McMenamin Subject: Re: [RFC][patch] filesystem: Vmufat filesystem, version 4 Date: Tue, 14 Apr 2009 08:00:29 +0100 Message-ID: <1239692429.6538.2.camel@localhost.localdomain> References: <1239654768.6542.10.camel@localhost.localdomain> <20090413210030.GA14847@linux-sh.org> <1239658604.6542.28.camel@localhost.localdomain> <20090413215949.GD14847@linux-sh.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: linux-fsdevel , LKML , linux-sh , "Josef 'Jeff' Sipek" , Sam Ravnborg To: Paul Mundt Return-path: Received: from mk-filter-1-a-1.mail.uk.tiscali.com ([212.74.100.52]:24114 "EHLO mk-filter-1-a-1.mail.uk.tiscali.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750761AbZDNHAk (ORCPT ); Tue, 14 Apr 2009 03:00:40 -0400 In-Reply-To: <20090413215949.GD14847@linux-sh.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, 2009-04-14 at 06:59 +0900, Paul Mundt wrote: > This file system is tied directly to the VMU. Assumptions about the > on-disk format, block numbering limitations, etc. are all VMU > constraints, and papering over that in the Kconfig text is not > sufficient. This file system is and always will be tied to the VMU, and > you really do not want to decouple the two. What you do in loopback mode > for testing is your own business, but this will not work in the way > people expect on a fixed disk. You are only making things harder on > yourself by insisting that this is somehow generic. > > The file system at least wants a dependency on the VMU (and I suppose > mtdblock) itself. Why won't it work on a fixed disk "in the way people expect"? Granted they'd be eccentric to format a disk in this way but there is no inherent reason why this file system *has* to be tied to a VMU.