[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: "processor" abstraction
Matt Thomas <matt%3am-software.com@localhost> writes:
> A lot of systems are coming with compute/peripheral processors with
> limited ram, etc.
> I was wondering what the abstraction should be?
> Obviously, mmap()'ing their memory would be nice. But what about
> stopping/starting? Messaging?
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". The current API cannot immediately
offer this because PT_GETREGS/PT_SETREGS takes a "struct reg" which is
tied to the host processor. But I think adapting ptrace() to be
"cross-arch friendly" would be nice and easy.
An idea to stick to existing abstractions for the coprocessor case could
be to have it launched as a stopped process. We could get the pid
through an ioctl on a dev node (used also for mmapping). Remaining
question: who does the process belong to? Must be root if it's started
automatically early by the kernel, but we could start it when someone
opens the dev node first with the credentials of the process opening the
Main Index |
Thread Index |