Jörn said:
> BTW: Did you already try to mmap /dev/mtd* or /dev/mtdblock* ?

Sure, but neither does implement the mmap method.

> One possibility to order the pizza is Joeys:
> http://www.joeys.de/joeys/65/index.htm

Gargl, I'll need to find my french/german dictionnary first (I'm in
the french speaking part of switzerland !) Should I drop you an email
before, or is a pizza always welcome ?

David said:
> Er, ditch the crap 'point' semantics and implement something sane for 
> mmapping, because that's about the only sane use of point() anyway.

Ok. What was the idea of unpoint, BTW ?

> That's not sufficient. If you let the erase or write operations happen 
> while it's mapped, what prevents your app from reading from the flash 
> _during_ the erase/write operation? You need to either prevent the erases/
> writes from happening while the flash is mapped (bad) or arrange for the 
> pages mapped to userspace to be marked invalid during the erase/write 
> operation, and faults on those pages have to wait until the flash is back 
> in read mode again.

I admit I looked at it from the narrow point of view of my single
process which is safe by construction... I do agree that the only
acceptable solution is the second (disallow page access during write /
erase).

> We want some kind of mtd_remap() call which has its own struct vm_operations,
> with a nopage() which sets a flag in the state of the underlying mtd_info, 
> and ensure that the page can be found again and made invalid before any 
> other MTD operations. With the rmap VM the latter is quite simple, without 
> it we'd need to keep track of all vmas ourselves.

I'm quite a newcomer to VM management (my only experience comes from
"Linux Device Drivers" and what I tested for this driver...). What is
the rmap VM ?

Frédéric