[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090110124335.GB30744@elte.hu>
Date: Sat, 10 Jan 2009 13:43:35 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Jörn Engel <joern@...fs.org>
Cc: David Brown <lkml@...idb.org>, Phil Oester <kernel@...uxace.com>,
Kay Sievers <kay.sievers@...y.org>,
Phillip Lougher <phillip@...gher.demon.co.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Christoph Hellwig <hch@...radead.org>,
torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [GIT PULL] Squashfs pull request for 2.6.29
* Jörn Engel <joern@...fs.org> wrote:
> On Fri, 9 January 2009 11:37:39 -0800, David Brown wrote:
> > On Fri, Jan 09, 2009 at 05:54:22PM +0100, Jörn Engel wrote:
> > >
> > > In general, filesystems and ABI changes are special because stupid
> > > mistakes are eternal. If some device driver has a bug, you can fix
> > > it, reboot and be done with it. Not so with filesystems.
> >
> > Squashfs is readonly from the kernel. The images are created with
> > userspace tools.
>
> While true, it doesn't make a difference. If, for example, your
> structures members are not naturally aligned, you take a performance hit
> for no good reason. Simply moving fields around would make the code go
> faster. But the format is fixed and prevents you from making this
> change.
>
> You have to get those things right from the beginning or pay for your
> mistakes everafter. In general (and I stress "In general") filesystems
> want more review than ordinary device drivers. And just to stress that
> again, this is not an argument against merging squashfs now.
What does a performance hit have to do with an ABI? Absolutely nothing -
if such a bug is noticed it is fixed, that's it. Your argument does not
parse and makes absolutely zero technical sense.
Your "ABI is forever" objection against a _read only_ filesystem is a
newbie mistake worthy of cookie file inclusion - i had a real good laugh
when i read it ;-)
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists