Re: frysk-core/frysk/proc ChangeLog IsaIA32.java I ...

[Andrew Cagney <cagney at redhat dot com>]

Phil Muldoon wrote:
> Moving forward, here is something I have been thinking about. As 
> Host/Proc/Task.java  are basically "contracts" of how a Host/Proc/Task 
> should be modeled on any system, they should in fact be straight 
> interfaces, not abstract classes. This achieves two things:
>
> 1) Stops code being placed in Host/Proc/Task that really should not be 
> there, but in some concrete class (implementor).
> 2) Just defines the structure of a Host/Proc/Task without placing any 
> expectations on its implementation. Implementation details should not 
> be a concept at this level.
>
> Furthermore the whole concept of a state machine should be moved 
> entirely to the implementing classes. I'm not sure how this will scale 
> throughout the frysk model, but a state machine is fake for a corefile 
> proc. It has no state, it's stone-cold dead. It will never live again 
> (I'm ignoring the fact that someday someone might try to resurrect the 
> process in its state just before it died). It will never spawn or lose 
> tasks.
>
> I'll take a radical view here and say the proc/ namespace is too busy. 
> In fact, I think the proc/ model should just have:
>
> - Interfaces
>
> - sub-packages like dead/ and live/ that implement the interfaces. In 
> those sub-packages should be all the ByteBuffer details that should be 
> entirely package private to stop instantiation of process specific 
> ByteBuffers. All tests, and so on.

Yes, exactly; much of what is in Task, and Proc should be booted down a 
level; mostly to frysk.proc.live.LiveTask.

> It's a germ of an idea at the moment, but something I've warmed too 
> over the weeks I've been thinking on it.
>
> Regards
>
> Phil