Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP

[JÃrn Engel]

On Sat, 9 June 2007 09:55:15 +0200, Carsten Otte wrote:
> JÃrn Engel wrote:
> 
> >Either that or using standard mtd->read() and mtd->write() calls.  I see
> >some advantages to mtd->write() in particular, as the device driver
> >needs some notification to trigger unmap_page_range() before the actual
> >write and chip state transitions happen.  mtd->write() seems much easier
> >than something like
> >
> >mtd->pre_write()
> >get_xip_page()
> >...
> >put_page()
> >mtd->post_write()
> >
> >If get_xip_page() only has userland consumers all the locking can be
> >kept inside device drivers.
> Hmmh. We won't need mtd->pre_write(), because the file system's 
> get_xip_page aop will have to ask mtd for the address anyway similar 
> to the way ext2_get_xip_page does call bdev_ops->direct_access.
> 
> If that call would pass the information whether the future access is 
> read-only or read+write, the device driver could do its housekeeping.
> 
> I think we should also cover put_page() plus mtd->post_write() inside 
> a put_xip_page() address space operation provided by the fs. This way 
> calls are balanced, and we have stuff in a single place rather then 
> duplicating code. The fs could rely on a generic implementation in 
> filemap_xip in case it does'nt need to do its own magic here.

That sounds like an awefully long critical section.  Remember, while the
write is going on (the chip isn't in read_array mode) the cannot be any
xip pages used anywhere in the system.  All existing mapping have to be
revoked and no new mappings created handed out while this goes on.

If we use a single call like mtd->write(), this critical section is
limited to one call and the device driver can keep it as short as
possible.  Having two calls and allowing crappy filesystems to spend a
long time between them... ugh.

Another thing that just dawned upon me is that the device driver must be
in control of xip.  You can partition a single chip and use two
filesystems on it.  If one fs is xip-aware and the other is, say, jffs2,
only the device driver can revoke mapping when jffs2 writes to the chip.

> >>- the device driver can access page->count via a helper function 
> >>provided by mm. This way, it can identify which pages are in use.
> >
> >One of us is confused here.  The driver would have to check page->count
> >for a large range of pages, usually the whole chip.  And it would have
> >to tear down every single mapping before starting to write.  Is that
> >possible and desirable to do with page->count?  Unsure.
> That point was indeed confusing. Let my try again:

You obviously have more experience with xip and quickly go into details
I don't understand yet.  So before I try to decipher your explanation
again, let me give you a very high level picture.  Something simple
enough for me to understand. :)

Fundamentally four kinds of functionality are required:
1 Handing out new xip pages for userspace.
2 Destroying xip pages for userspace.
3 Temporarily revoking any pages given out for current writes.
4 Handling page faults on revoked pages.
5 Reenabling revoked pages.

AFAICS, 1 and 2 are required for dcss xip as well.  3 is new and only
necessary for flash.  4 should be mostly old, 5 again is new.

Most likely 3 will require a TLB flush on most architectures plus some
provisions that page faults on the xip pages are handled by putting the
processes on a wait queue, done in 4.  5 will remove those provisions
again, wake everything on the waitqueue and allow userspace to proceed
accessing xip pages.

Roughly sane?

JÃrn

-- 
To announce that there must be no criticism of the President, or that we
are to stand by the President, right or wrong, is not only unpatriotic
and servile, but is morally treasonable to the American public.
-- Theodore Roosevelt, Kansas City Star, 1918
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/