[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 |
HI,
On 3/29/07, olafBuddenhagen@gmx.net <olafBuddenhagen@gmx.net> wrote:
Hi,
That's what I mean, yes. (Replacing before calling
hurd_file_name_lookup().)
> 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
http://lists.gnu.org/archive/html/bug-hurd/2007-03/msg00050.html
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.
Regards,
Wei Shen