>> [...] 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B