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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
