Re: [PATCH] kern: simple futex for gnumach (version 4)

[Marin Ramesa]

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.