Re: [CapROS-devel] Recommended change to process state

[Jonathan S. S. <sh...@er...>]

I am learning about the perils of wireless-capable cell phones.
Responses are necessarily terse, and they are often unclear as a
result. :-)

On Thu, 2005-10-20 at 13:13 -0700, Charles Landau wrote:
> >No. I was saying that it was still possible to have a process of 
> >exactly one page.
> >
> >In fact I think it's a bad idea.
> 
> Why?

Because too many pieces of the runtime system know (at least implicitly,
often explicitly) about the shape of the address space. When we code the
C library, we make de facto assumptions about the feasibility of using
malloc(), the existence of a sizable protective gap between top of heap
and bottom (address-wise) of stack, presence or absence of a capability
address space, direction of stack growth, and so forth.

Each of these assumptions, taken individually, can be altered; however,
each of these changes involves building a different runtime support
system. Each of these runtime systems must be maintained, and the
interactions are subtle and complicated. When we introduced small spaces
in EROS, I found that even this (seemingly simple) change had
consequences in the runtime system.

So: I think it is best to have one runtime model.

On the other hand, given the low (and still falling) cost of memory, I
don't think that the space concerns of the 1970's are quite such
overriding concerns today as they were then.

There are a few "iron man" domains/processes that need to do their own
runtime. These should be kept to the least number possible, and the rest
of the system should be as uniform as possible.

> >But do not move the register images.
> 
> Why not?

Because the virtual registers page is a kernel-defined data structure.
Period, full stop. The application can choose the virtual address at
which this page is mapped in the application space, but it is the
kernel's decision how the page is laid out. Further, the content of this
page is part of the kernel/user interface and needs to be evolvable over
time. Any application that chooses to make use of "spare" area in the
page does so at its own risk and at the risk of future incompatibility.

My opinion is that the kernel data structures should have their origin
at page offset zero. This is because the payload will inevitably grow
and/or change over time, and it is much easier to append things to data
structures than to prepend them.

There is also the possibility of allowing the application to specify the
page-relative offset of the data structures. This is simply stupid. We
do not allow applications to specify the starting offset of its
capability register numbers, and in the same way we should not permit
this. This state is part of the kernel process model. If the application
wants to use its own state for its own purposes, that's wonderful, but
the application should get its own bloody state to do it in.

The really interesting design question about the registers

> 
> >This page is kernel process state, mappable only by courtesy.
> 
> But:
> At 6:24 AM -0400 10/20/05, Jonathan S. Shapiro wrote:
> >It is up to the process to decide where/how to map this page into the
> >application visible address space.
> 
> I understood that it *had* to be mapped somewhere so the process 
> could read and write the pseudoregisters in it.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> CapROS-devel mailing list
> Cap...@li...
> https://lists.sourceforge.net/lists/listinfo/capros-devel