l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: space banks and DMA


From: Jonathan S. Shapiro
Subject: Re: space banks and DMA
Date: Thu, 13 Oct 2005 14:18:35 -0400

On Thu, 2005-10-13 at 14:24 +0100, Neal H. Walfield wrote:
> How do you deal with DMA?

Badly, probably, but let me try to answer you.

>   The specific scenario that I'm think of is
> when a task wants to read a block from disk.  I imagine that the task
> invokes an appropriate capability supplying a space bank from which
> the server will allocate a frame to store the read data.

Not at all. Remember: EROS is transparently persistent. The page that
you allocate from the space bank is a *disk* page. It is the kernel's
job (in collaboration with drivers) to move that page to and from the
disk as needed.

There is no mechanism in EROS for allocating page frames in the sense
that you describe here. There *is* a design for a working set mechanism
that has never been completely implemented, but one does not do DMA into
working sets.

I will answer your DMA question more properly in a separate note, but it
seemed important to clarify this first. I am going to have to answer in
two parts: how persistence works and how general DMA works.

But here is an important hint: anything that does DMA is inherently part
of the TCB. It may run as application code, but it carries all of the
same authority as the kernel because it is in a position to overwrite
the kernel using its DMA engine.

In consequence, there are *lots* of things that we can reasonably do in
these cases that would be completely unacceptable for applications in
general.

shap





reply via email to

[Prev in Thread] Current Thread [Next in Thread]