> Those void functions you changed to error_t can never fail, so I don't see
> the point. The actual diskfs_make_node changes seem ok.
They can never fail today, however, I thought it made the interface a
bit more consistent. I guess, however, you are right, there is no
need.
Here is revised p
Those void functions you changed to error_t can never fail, so I don't see
the point. The actual diskfs_make_node changes seem ok.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
[EMAIL PROTECTED] (Niels Möller) writes:
> This sounds a lot like having a mach-port-server that handles all ipc.
> Is that the way to go? How efficiently can the extra redirection be
> handled in L4?
>
> If we go in this direction, there's no real use of any L4-security;
> the only mechanism th
The way we use diskfs_make_node is currently unsafe: we almost never
check the return value, however, we really should. The following
patches fix this. However, rather than simply correcting the
problems, I opted to fix the error at its root: the interface. Now,
we return an error code and plac
Volkmar Uhlig <[EMAIL PROTECTED]> writes:
> The general idea in L4 is to have a server which creates and deletes
> tasks. This server "owns" the tasks and is the only one allowed to
> execute the task_new syscall for them. L4 tries to keep task allocation
> policy out of the kernel allowing user
> > When a task dies, its resources need to be all cleaned up. If it's
> > the last task with the right to send to that port, then a no senders
> > notification should be sent. If we rely on the task to do so itself,
> > then sometimes it will not happen due to task misbehavior.
> The general id
