Re: "processor" abstraction

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> [...] compute/peripheral processors [...] abstraction [...]

> How about using/extending the ptrace API to handle this?  It looks
> like the primitives required are the same (+mmap you mention).

> And it would make sense to be able to attach to a
> qemu/coprocessor-provided "process".  [...]

> An idea to stick to existing abstractions for the coprocessor case
> could be to have it launched as a stopped process.  [...]

I like this in general.  But there's a potential issue I see: the
ptrace interface is designed for userland processes, so its CPU state
interfaces contain only the stuff appropriate to userland.  But
coprocessors have their own, separate, notion of privileged state;
getting and setting coprocessor state would involve a bunch of stuff
ptrace is not prepared to handle.

It's possible fixing this could be rolled into the cross-arch fixes
that would be necessary.  But it's also possible it's not that simple;
I haven't though about it for more than a few minutes.

It would also mean extending your process abstraction, since the
`process' running on a coprocessor differs in some significant ways
from an ordinary host process.  Again, this might be easy, but it also
might not.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B