From: David Woodhouse <dwmw2@infradead.org>
To: Alexander Larsson <alex@cendio.se>
Cc: mtd@infradead.org
Subject: Re: Preliminary documentation.
Date: Tue, 28 Mar 2000 16:11:11 +0100 [thread overview]
Message-ID: <19717.954256271@devel2.axiom.internal> (raw)
In-Reply-To: <Pine.LNX.3.96.1000328155631.345A-100000@biffen.cendio.se>
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
prev parent reply other threads:[~2000-03-28 15:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-03-28 10:49 Preliminary documentation David Woodhouse
2000-03-28 14:11 ` Alexander Larsson
2000-03-28 15:11 ` David Woodhouse [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19717.954256271@devel2.axiom.internal \
--to=dwmw2@infradead.org \
--cc=alex@cendio.se \
--cc=mtd@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox