Subject: Re: NAMECACHE_ENTER_REVERSE (Re: CVS commit: src/sys/kern)
To: None <>
From: Christos Zoulas <>
List: tech-kern
Date: 11/29/2006 00:00:57
In article <>,
YAMAMOTO Takashi <> wrote:
>> >it's wrong because our name cache is optional.
>> >ie. a filesystem is free to choose not to use it at all.
>> >please revert.
>> If the filesystem does not implement it, it fails with an error.
>> Actually I have a good idea how to deal with the failure in the
>> procfs "exe" case.
>then, what's a problem with just failing always and deal with it?

Some linux-emulated rdbm's don't work.

>> >(besides, i don't think it works as linux procfs expects,
>> >because there entries are not pinned.)
>> I think it is good enough for the purpose required
>> (to find any path to the vnode requested).
>i'm not sure what you mean.
>if name cache entries are not required for your purpose,
>there is no point to enter it in the first place, isn't it?

It works all the time in this case, because we can make it fail
back to /proc/<pid>/exe -> /proc/<pid>/file

>> >if vnode -> name translation is really necessary, it should be
>> >implemented in upper layers.  (caller of VOPs, not filesystems.)
>> how? can you please elaborate?
>something similar to what linux and dragonflybsd do.

I did not want to keep a full pathname buffer in struct proc. There
is also the issue of the binary being renamed/removed. I guess those
are corner cases that are not worth discussing though.