On 12/24/2013 11:41:40 AM, Richard Braun wrote:
Obviously, you rushed your work without trying to understand what you
were doing, and this is becoming frustrating. Don't blindly and
mindlessly copy the first thing you see around...
1/ A simpleroutine is a one-way RPC, without a return value other than
that of the message transmission.
2/ Futex calls should operate on futexes, not threads. If you actually
only want to specify addresses in the calls, use a task_t as first
parameter, because there is no risk of right reference leak when
calling
mach_task_self, whereas there are with mach_thread_self.
And again, I insist on *not* creating ioctl-style calls with an
"operation" parameter. The operation is the RPC itself. Also, AIUI,
the
operations are wait and wake, so why create a third "futex" RPC ?
To finish with, don't suffix RPCs with "_rpc" ...
OK, I won't write RPCs. It was a bad idea.
Personal question: why are you working on this ?
I need to start somewhere. I really want to learn how kernels are
programmed.
This task was listed in the small hacks entry, I really thought it
would be a
small hack.
Considering the
beginner mistakes you did at the C level itself, and that you've never
even run a real GNU Mach instance,
OK, I installed Debian Hurd. I'm running it and testing the calls.
what makes you think you have the
proper experience to work on such a low-level tool that involves both
virtual memory and concurrency, two of the most difficult domains in
computer science ?
There is a one call to vm_map lookup to retrive the offset and the
object. Simple
locks are used and there are calls to thread_resume() and
thread_suspend(). I don't
see anything so much difficult that I can't learn while doing it.
But I won't work on this if it's frustrating. I don't want to cause any
trouble.
