Re: GNU Hurd SoC projects

[olafBuddenhagen]

Hi,

On Mon, Mar 26, 2007 at 11:47:09PM +0800, Wei Shen wrote:
> On 3/25/07, olafBuddenhagen@gmx.net

> 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?

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.

Note that we can't *force* a process to use a specific server by
client-side means anyways; after all, it can do it's own name lookup if
it wants, instead of using the glibc function.

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

> Moreover, it is still not a centralized solution.

Indeed, as I pointed out myself:

> >While this would require adoptions in libc for every server
> >individually,

However, I don't think the task requires it to be a centralised solution
-- especially as some servers (like exec) need special handling anyways.
And, as I also pointed out:

> >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.

So it has some advantages also. Don't know which is the better approach,
but I think the possibility shouldn't be rejected up front without
further investigation.

-antrik-