Subject: Re: NAMECACHE_ENTER_REVERSE (Re: CVS commit: src/sys/kern)
To: None <email@example.com>
From: Christos Zoulas <firstname.lastname@example.org>
Date: 11/29/2006 00:00:57
In article <20061128220609.53B8211705@yamt.dyndns.org>,
YAMAMOTO Takashi <email@example.com> 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.