Preliminary documentation.

Preliminary documentation.

[David Woodhouse]

I've now put written up the documentation I wrote out by hand last night.
It's at http://www.linux-mtd.infradead.org/tech/

Comments, please. I haven't yet filled in my suggested restrictions on the 
read/write functions, but I have removed the retlen arguments.

As I said, I'm changing the notifier stuff to make it cleaner. I have yet to 
actually change the code to fit in with my new documentation. 

Also, a couple of questions on the decisions I've made:

1. Is mtd->sync() enough, or could users want more access to the erase queue?

	We could add 
		struct erase_info *mtd->eraseq;
		spin_lock_t	mtd->eraseq_lock;
	... and allow users to use that.

2. Is the callback in the erase_info OK or would we be better off having a 
wait_queue_head_t instead (or as well)?






--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Preliminary documentation.

[Alexander Larsson]

On Tue, 28 Mar 2000, David Woodhouse wrote:

> 
> I've now put written up the documentation I wrote out by hand last night.
> It's at http://www.linux-mtd.infradead.org/tech/
> 
> Comments, please. I haven't yet filled in my suggested restrictions on the 
> read/write functions, but I have removed the retlen arguments.
> 
> As I said, I'm changing the notifier stuff to make it cleaner. I have yet to 
> actually change the code to fit in with my new documentation. 

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...)
  
Then just remove the point/unpoint calls.
 
> Also, a couple of questions on the decisions I've made:
> 
> 1. Is mtd->sync() enough, or could users want more access to the erase queue?
> 
> 	We could add 
> 		struct erase_info *mtd->eraseq;
> 		spin_lock_t	mtd->eraseq_lock;
> 	... and allow users to use that.

Nah, i don't think many people would use that. And it would limit the
driver implementation a bit.
 
> 2. Is the callback in the erase_info OK or would we be better off having a 
> wait_queue_head_t instead (or as well)?

I think the callback is enough, if people need a wait queue they could
make one themself from the callback.

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.

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

Is struct erase_info.mtd filled in by driver or user?

I like the driverpriv proposal.

/ Alex





To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Preliminary documentation.

[David Woodhouse]

alex@cendio.se 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
problems.

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@cendio.se 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.


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org