Thanks for your advice.
On 3/25/07, olafBuddenhagen@gmx.net
On Sat, Mar 24, 2007 at 06:00:24PM +0800, Wei Shen wrote:
> 2) Let the root fs server judge which server port to return on a
> specific name qurry.
> 3) Modify hurd_file_name_lookup function in the C lib. If necessary,
> replace the default sever name to the name of an overiding server
> before qurring the root fs.
Note that both of these approaches are really specific single-purpose
implementations of local namespaces. (The former server-side, the latter
client-side.) I'm not saying this is bad or anything -- just an
interesting observation.
Yes, they are.
For comparision, did you evaluate the straight-forward approach to check
environment variables in libc *before* the name lookup?
I.e. instead of
diverting the name lookup of the default location, first check whether a
different location is requested, and lookup this one instead?
I can not see why it is different from approach 3). Are hurd_file_name_lookup not in libc? Or you mean replacing the name 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? Moreover, it is still not a centralized solution.
While this would require adoptions in libc for every server
individually, the changes should be rather small and obvious, so I guess
it might still be an interesting alternative to the more generic but
much more complicated namespace approach...
This would also avoid any possible performance implications, as the path
for normal filesystem lookups wouldn't be altered.
What do you think?
Note that the exec server needs special handling, because it's not
invoked from the application process directly, but from the filesystem
server on behalf of the application. There is no way to override it
per-application directly (you could only override *all* execs on a
specific filesystem); thus the forwarding done by the default exec
server instead. For most other servers, such special handling shouldn't
be necessary, though.
-antrik-
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd