alex at cendio.se
Tue Mar 28 09:11:08 EST 2000
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
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.
To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org
More information about the linux-mtd