RE: asm/unistd.h and asm/ptrace.h and the Hurd
> So, I guess the basic question is "Does the hurd provide a
> way to determine if a particular process is spawning itself
> or cloning a subprocess".
What do those terms mean? There is nothing called "spawn" or "clone" in
Mach, Hurd, or Unix in general. Are you talking about fork? About exec?
About creating new threads?
As in Unix, after doing `ptrace(PTRACE_TRACEME)' in a Hurd process, that
process will take a SIGTRAP when it exec's a new program. When a Hurd
process forks, the child process does not stop (its "traced" flag is
cleared). It would certainly be possible to have some special ptrace
interaction with fork if there are specific other semantics that are useful.
> I image that the answer is yes, but I assumed that this information would
> be part of the C Library -- so I was suprised to see the /asm linkage.
I really don't know what you are talking about here. What does "/asm
linkage" mean? Are you referring to the Linux asm/*.h header files that
you spoke of earlier? If so, I was evidently not clear enough in saying
that these files have no possible relevance to your questions.
> As for ptrace, it falls into the same category as unistd.h --
> ltrace expects to be able to get some architecture-specific
> information about the ptrace call stack (I suppose it wants
> to know what information is stored in what manner during
> a system call). I really haven't looked into why this is
> useful to ltrace at the moment.
I am finding this is quite vague and confusing. I really do not know what
information you are talking about, or what you mean by "the ptrace call stack".
> When searching through the hurd and gnumach sources, I found
> that these headers are used for the device drivers that have
> been brought over from Linux. I then wondered if they
> (or their analogs) would be accessible from the Hurd or
> gnumach.
>
> So, leaving the ptrace stuff for the time being, is it
> possible to determine the nature of any of the linux-ish
> system calls that might be made from a running program,
> specifically to identify fork, vfork, or clone calls?
My prior message clearly failed to communicate the essential points. Let
me be more direct: To understand Mach and the Hurd, do not read the gnumach
sources. Read ONLY the installed files in /include, and read the libc and
Hurd sources.
The Hurd is really a very different system from Linux, and the Mach
microkernel does a very different set of things than the Linux kernel. The
code that you have been reading has absolutely nothing to do with anything
at all (except the device drivers), and there is nothing whatsoever like
the analogs to Linux system calls that you seem to be looking for. Every
piece of the API that is a system call in Linux is a library function
(implemented in libc) in the Hurd.
Reply to: