The following reply was made to PR lib/30664; it has been noted by GNATS.

From: christos@zoulas.com (Christos Zoulas)
To: yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
Cc: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org,
	netbsd-bugs@netbsd.org, gnats-admin@netbsd.org, xtraeme@netbsd.org,
	juan@xtrarom.org, core@netbsd.org
Subject: Re: kern/30664
Date: Fri, 6 Apr 2007 11:36:41 -0400

 On Apr 6, 11:44am, yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
 -- Subject: Re: kern/30664
 
 | [ moved from PR/35675 ]
 | 
 | > | > I am looking for something like solaris' resolvepath(2) which can be
 | > | > used to implement the rest of realpath(3) in userland.
 | > | 
 | > | it isn't necessary to solve these PRs, right?
 | > 
 | > I think that it is a lot easier to handle magiclinks in one place
 | > (kernel since this is where we resolve them now) as opposed to
 | > either introduce a new system call that resolves them, or copy the
 | > code to userland.
 | > 
 | > christos
 | 
 | whatever libc realpath implementation is, there is no way to force
 | applications to use the kernel version.  so, as far as we keep the current
 | semantics of magiclinks, we need to modify readlink(2) anyway.
 | and, if we choose to adapt readlink(2), there is no need to modify realpath.
 
 Yes, we'll need to modify readlink anyway. I think that the magiclinks
 should be transparent to userland, except possibly to have magic readlink2()
 system call that returns them unresolved. I am not even sure if this is
 necessary.
 
 | i'm not saying having resolvepath(2) is a bad idea.  (actually, i'm not sure.)
 | i'm merely saying it isn't necessary for these PRs.  don't you agree?
 
 I agree it is not necessary, but it is a good idea to have nevertheless,
 since most of the code is already present in the kernel.
 
 christos