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

From: Elad Efrat <elad@9of9.org>
To: Christos Zoulas <christos@zoulas.com>
Cc: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, gnats-bugs@NetBSD.org,
	core@netbsd.org
Subject: Re: kern/35675 (magiclinks implementation broken)
Date: Thu, 05 Apr 2007 19:30:29 +0200

 Christos Zoulas wrote:
 
 > | > 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.
 
 I agree. like I said elsewhere, there is (going to be) a need to reverse
 lookup a pathname based on a vnode in the kernel. also, the
 implementation details of magiclinks should remain internal to the
 kernel.
 
 the logic is that magiclinks should not require special handling, or
 they don't really achieve anything. so their resolution should be
 handled like any other path component. combining that with the outlined
 need for kernel routine to reverse lookup a pathname based on a vnode,
 it may make most sense to store this code in the kernel and "share" it
 to userland via a resolvepath(2) syscall (that will replace the guts of
 realpath(3)) in libc.
 
 -e.