Re: GNU Hurd SoC projects

> 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-purposeimplementations of local namespaces. (The former server-side, the latterclient-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 checkenvironment variables in libc *before* the name lookup?
I.e. instead ofdiverting the name lookup of the default location, first check whether adifferent 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 serverindividually, the changes should be rather small and obvious, so I guess
it might still be an interesting alternative to the more generic butmuch more complicated namespace approach...

This would also avoid any possible performance implications, as the pathfor normal filesystem lookups wouldn't be altered.

What do you think?

Note that the exec server needs special handling, because it's notinvoked from the application process directly, but from the filesystemserver on behalf of the application. There is no way to override it
per-application directly (you could only override *all* execs on aspecific filesystem); thus the forwarding done by the default execserver instead. For most other servers, such special handling shouldn't
be necessary, though.