Subject: Re: kern/30664
To: None <lib-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: netbsd-bugs
Date: 04/06/2007 02:45:02
The following reply was made to PR lib/30664; it has been noted by GNATS.

From: yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
To: christos@zoulas.com
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:44:15 +0900 (JST)

 [ 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.
 
 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?
 
 YAMAMOTO Takashi