Re: Comments on the hurd-on-l4 document

[Marcus Brinkmann]

At 07 Jun 2005 18:54:51 +0200,
Niels Möller wrote:
> Section 6.2.1: Signals
> 3. "However, in Unix, there is always a race when sending a signal
>     using kill. The task server helps the users a bit here by not
>     reusing task IDs as long as possible."
> 
> I think 3 is plain wrong. When you write kill 4711 at the shell,
> there's a race condition, but that's far from the only way to use
> signals.

This is the generic case and that's the race meant. 

> When using kill to a child process, there's no race
> condition, since one is guaranteed that the pid isn't reused until the
> parent process has called one of the wait system calls.
>
> At least this use case must be supported without any races.

True, and it will quite naturally be without a race, I guess.

> And there's one more issue I'd like to mention, and that is the
> interaction with exec.

I am not sure my understanding of the signal system is good enough to
comment on that right now ;)

> And even if we can't guarantee delivery of the signal, we need to
> provide some way for proc clients to deal with the fact that the
> signal thread for a process can change over time. We could require
> that the client asks proc "is this still the signal thread for process
> 4711?" everytime it sends a signal, but perhaps it can be handled in a
> smarter way.

I am not sure that can be done safely.  You could refetch the
communication port from proc when the one you have becomes invalid.
It depends a lot on the details of the IPC system, though.

> Section: 6.5.1 Directory lookup across filesystems
> 
> I'm not sure I understand all the subtleties here, but for the
> protocol side of it, I think it makes a lot of sense to do it in two
> phases, as you sketch:
> 
>   dir_lookup(directory, name)
> 
> never follows any translators, it just returns a capability for a node
> and a flag that is set if there's a translator on top of the node. And
> then use a completely separate call to follow the translator, if
> desirable,
> 
>   translator_lookup(node)

Good idea, and seems to make sense to me.

> Section 8.8: Order of implementation
> 
> I know I shouldn't really argue about this since I'm not hacking on
> the thing, but I have a strong feeling that one ought to start with
> the very minimalistic "framework" needed in order to get some stupid
> but working drivers for console, keyboard and IDE drive in place. But
> you all probably knew that already.

In fact, a functional minimal console is already implemented in a very
cheesy way.  Ie, you can write a root server that uses RPCs on a
console port to read and write console data.  It's veeery minimal.  An
IDE driver wouldn't be too hard at all, but of course the issues lie
elsewhere, like in how to manage access and caching etc.

Thanks,
Marcus