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