Preliminary documentation.

David Woodhouse dwmw2 at
Tue Mar 28 10:11:11 EST 2000

alex at said:
>  A suggested API for fully memory-mapped devices:
>  void lock(struct mtd_info *mtd);
>  void unlock(struct mtd_info *mtd);
>  u_char *mapped; /* may be NULL if not memory mapped device */
> (The "mapped" name could be better...)

I see the most common use of this being when you want to do XIP.

So you're going to want to map it into userspace and leave it mapped - which
means that locking the device for the duration is going to cause significant

I think the best option might be to let the driver manipulate the page tables 
itself. That way it could do XIP even if it's paged and not 100% mem-mapped, by marking pages as absent, and dealing with page faults as and when they arrive.

alex at said:
> Another thing. The void *priv field in the struct mtd isn't neccesary.
> As the structure is allocated by the driver the driver could allocate
> a larger structure (with a struct mtd as first field) and completely
> hide internal data.

I've never thought it very neat to do that kind of thing, although I suppose 
it's safe enough in this case.

>  Why is there a size field in struct erase_info if it must always be
> the size of the mtd erase block size? 

I pondered that as I was writing it up - we ought to either remove it or make 
it legal to use it. I prefer removing it, but left it there at the time mainly 
so that I remembered.


To unsubscribe, send "unsubscribe mtd" to majordomo at

More information about the linux-mtd mailing list