Message-ID: <6934efce0706071559j24978c15kc42914677dc8408e@mail.gmail.com>
Date:	Thu, 7 Jun 2007 15:59:00 -0700
From:	"Jared Hulbert" <jaredeh@...il.com>
To:	"Christoph Hellwig" <hch@...radead.org>,
	"Jared Hulbert" <jaredeh@...il.com>, carsteno@...ibm.com,
	"Nick Piggin" <nickpiggin@...oo.com.au>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	richard.griffiths@...driver.com,
	"Richard Griffiths" <res07ml0@...izon.net>,
	Linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP

> If if were actually talking about complex filesystem I'd agree.  But
> the cramfs xip patch posted here touches about 2/3 of the number of
> lines that cramfs has in total.

Fair enough.  But look at the complexity rather than number of lines.
It adds tedium to the cramfs_fill_super and one extra level of
indirection to a hand full of ops like mmap() and cramfs_read().  But
the changes to the real meat of cramfs, cramfs_readpage(), are limited
to the XIP changes, which I want on block devices anyway.

So if we did fork cramfs I would submit a simple patch to cramfs for
XIP support on block devices and I would submit a patch for a new
filesystem, cramfs-linear.  Cramfs-linear would have an exact copy of
1/3 of the cramfs code such as cramfs_readpage(), it would use the
same headers, and it would use the same userspace tools.

This fork is what the community wants?  Speak up!

>And cramfs is not exactly the best base to start with..

This is a moot point, there is a significant installed base issue.
There are lots of cramfs-linear-xip based systems in existance with
can't be easily ported to newer kernel because of a lack of support.

> > This is nirvana.   But it is not the goal of the patches in question.
> > In fact there are several use cases that don't need and don't value
> > the writeability and don't need therefore the overhead.  It is a long
> > term goal never the less.
>
> With the filemap_xip.c helpers adding xip support to any filesystem
> is pretty trivial for the highlevel filesystem operations.  The only
> interesting bit is the lowlevel code (the get_xip_page method and
> the others Carsten mentioned), but we need to do these lowlevel
> code in a generic and proper way anyway.

It's not that trivial.  The filesystem needs to meet several
requirements such as, having data nodes that are page aligned.
Anytime any changes are made to any page in the underlying Flash block
or if the Flash physical partition goes out of read mode you've got to
hide that from userspace or otherwise deal with it.  A filesystem that
doesn't understand these subtle hardware requirements would either not
work at all, have lots of deadlock issues, or at least have terrible
performance problems.  Nevertheless I supose a simple, but invasive,
hack could likely produce a worthwhile proof of concept.

I think this is worthy of it's own thread....

> I'll try to hack up an xip prototype for jffs2 next week.

Very cool.  I can't wait to see what you have in mind.  But remember
this doesn't solve the problem of the huge installed base of
cramfs-linear-xip images.

Gee I think it seems logfs would be a better choice.  Jffs2 and
ubifs(jffs3) for that matter combine node and node header in series
which means your data nodes aren't aligned to page boundarys. Logfs
nodes could be more easily aligned.
-
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