A few questions about the hurd-ng draft

[Michal Suchanek]

Hello

I downloaded the hurd-ng draft (through the link on the wiki). It
says it is from March 16 so I guess it is current.

I wonder what is uid_t - what does it specify, what is meaning of
values of that type. Did I miss it in the draft?

I see it used in the syslog specification. However, I would rather see
a capability based syslog.

ie. create a syslog queue with read, write(create), and notify capabilities.
The queues could be symbolically named by stuffing references to them
into a directory.
You would give out the write capability of a queue to processes, and
the read (and notify) capabilities to user shells or whatever you
like.

There might be a problem with revoking capabilities to the queue. But
targetting the events at some uid does not look better to me.

Also logging on Posix is sort of best effort.I wonder if it can be
better. In Linux kernel there is a ring buffer that syslog polls for
new messages. Other messages are sent diretly to syslog. But I have no
idea how syslog can handle arbitrary amount of messages and be
expected to respond in reasonable time. Can the messages be delivered
to more than one recipient/holder of the read capability?


Is it necessary to have process signals? I guess that some method that
actually can pass data is needed, and pipes should be able to do that.
Or what is the advantage of signals?

Where does one get the process_exit capability? Can multiple such
capabilities be generated so that multiple processes can be notified?
Who sends the notification - is it reliable?

I wonder why dir_lookup rpc does include 'magic' for iterative lookup
but the other methods do not. There was a discussion about (not)
supporting filenames of arbitrary length. If all dir methods supported
'magic' this could work.

Thanks

Michal