Hi, On Mon, Mar 26, 2007 at 11:47:09PM +0800, Wei Shen wrote: > On 3/25/07, [EMAIL PROTECTED]
> 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- _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
