Re: [CapROS-devel] deleting domState

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

On Sat, 2007-08-18 at 10:58 -0700, Charles Landau wrote:
> For SetRegisters, this field should never have been used. It could 
> cause kernel inconsistencies (resume key exists while process is not 
> Waiting), and there are more sane ways of changing the run state.

The intent was that any transition from waiting to non-waiting should
invalidate all outstanding resume capabilities.

> For GetRegisters, I've concluded it is unnecessary because the state 
> can usually be inferred from other information. If there is a fault 
> code, the process is Waiting on a keeper call, or about to make a 
> keeper call. If the expectingMsg flag is on, the process's PC points 
> to an invocation instruction and the state is Waiting or Available if 
> the invocation is a Call or Return, respectively. Otherwise the state 
> is Running.
> 
> It's less convenient to get the Running/Waiting/Available state by 
> inference, but there is currently no user code that actually wants it.
> 
> Therefore I'll delete domState.

I think this is a mistake -- debuggers want precise information. A
better solution might be to ignore the field for SET.
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC