[PATCH][MTD] mtdpart.c: allow other drivers to get physical address of partition

[Jörn Engel]

On Fri, 3 August 2007 12:45:45 -0700, Jared Hulbert wrote:
> 
> > > Perhaps we want to set it up so that _if_ there is a process which can
> > > continue, it'll do so. Only when there's nothing runnable in userspace
> > > do we suspend an erase? In that case, perhaps we'd want some kind of
> > > hook in the idle loop?
> >
> > Or we could just always suspend the erase and resume it the next time we
> > enter the kernel, either via system call or interrupt.  Should allow the
> > process to make some progress without starving the erase.  Would need
> > hooks as well, just in different places.
> 
> Hmmm, we'd definitely benefit from having a hook in idle to trigger
> the erase to resume.  Having hooks for entry into kernel space sounds
> interesting, but if you leave it too quickly and suspend the erase you
> don't make forward progress.  However, I'm not sure how you'd
> determine whether a given process can continue without suspending the
> erase.

Does the system ever idle in a userspace process?  If not then you'd
have to come by one of my hooks before going into idle.

Even better, if the process does a system call, or an interrupt happens,
it will not access the XIP pages while the syscall/interrupt is
processed.  So the erase may as well resume for the time being.  And
potentially it can even run a little longer if no XIP faults happen.

The big question is how such a scheme would perform.  It may turn out so
bad that we should rather copy the data, hand out RAM and wait for
memory pressure to remove those pages again.

Jörn

-- 
I don't understand it. Nobody does.
-- Richard P. Feynman