In article <20061128220609.53B8211705@yamt.dyndns.org>,
YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp> 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.

christos