[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Hurd SoC projects

From: Wei Shen
Subject: Re: GNU Hurd SoC projects
Date: Thu, 29 Mar 2007 10:35:00 +0800


On 3/29/07, olafBuddenhagen@gmx.net <olafBuddenhagen@gmx.net> wrote:

That's what I mean, yes. (Replacing before calling

> If so, how can we handle the case that applications directly call
> hurd_file_name_lookup to find a server?

Interesting question... Of course, this case wouldn't be covered. But I
wonder how likely applications are actually to attempt this, and whether
it's a good idea to try to catch this if they do -- I'd guess such a
situation would mean they want to do something very special.
Maybe, you are right. I have to further investigate before a conclusion.
But I still suspect it is not good for security reasons - we may want a process to  use a overriding server blindly. And, I think in a micro-kernel based multi-server OS, we should provide applications more flexibility rather than forcing the standard lib and standard interface of a lib.
The server-side variant (approach 2) could enforce this. I'm not
convinced though that implementing local namespaces in all the
filesystem servers is a good thing. A more hurdish solutions seems using
proxy filesystem servers. Also see my comment at

I read it, but do not like the idea. I think it costs too much to matain an entire namespace for each process. At least, for overring limited default servers, it does not deserve the expense.
I agree with your comments on environment variables. Using them is not user-friendly, and not good for control.
Thanks again for your advice. Discussion with you give me much help.
Wei Shen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]