public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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

      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