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.)
