Re: asm/unistd.h and asm/ptrace.h and the Hurd
It's not entirely clear to me what you are asking.
The source files from Linux that you find in the gnumach sources are part
of the implementation of device drivers within the kernel. They have
nothing whatsoever to do with the Mach kernel interface or anything about
the Hurd. The kernel interfaces are those found in the header files
installed in /include by gnumach, glibc, and hurd.
The kernel interface proper is in the <mach/*> and <device/*> headers and
.defs files (a .defs file is a MiG specification of an RPC interface); the
necessary support code, and some necessary headers, for programs to access
the kernel interfaces, reside in libc and the <mach*> headers it installs.
Because we take device drivers from Linux for gnumach, we take various
other source files (some verbatim, some modified) that form part of the
glue code necessary to compile the Linux device driver code into gnumach.
But that is an implementation detail internal to the gnumach source and not
relevant to the Mach or Hurd APIs in any way. When talking about the Hurd,
it makes no more sense to refer to these Linux-derived headers in the
gnumach source than to refer to the kernel-internal headers found in
kern/*.h and other parts of the gnumach source.
All that said, I'm sure there is an underlying problem you're trying to
solve that led you to investigate the kernel source and become confused by
this issue. I imagine you're trying to port ltrace or strace.
The notion of a "system call" in Unix really just does not apply to the
Hurd in the same way at all. (That's why I said don't try to port strace,
the closest equivalent would be an rpctrace.) For ltrace, at least for now
just avoid trying to port those parts where it thinks it knows about the
notion of a system call (by intercepting the libc functions like `read' et
al, ltrace can be very useful without doing anything about "system calls"
per se).
If you have specific questions about how to use the ptrace interface on the
Hurd, please ask about exactly what you are trying to do. (The more I
think about this, the more I think that making ptrace really usable for
frobbing thread states is not worth the trouble and the better thing would
be to use Mach directly or abstract the code from gdb into a new library
with an interface that's more intelligent about threads than ptrace.)
Reply to: