Re: Filepaths in VM map for tmpfs files

On 02/03/2015 02:33 PM, Konstantin Belousov wrote:
> On Mon, Feb 02, 2015 at 09:50:22PM -0600, Eric Badger wrote:
>> On 02/02/2015 03:30 AM, Konstantin Belousov wrote:
>>> On Sun, Feb 01, 2015 at 08:38:29PM -0600, Eric Badger wrote:
>>>> On 01/31/2015 09:36 AM, Konstantin Belousov wrote:
>>>>> First, shouldn't the kve_type changed to KVME_TYPE_VNODE as well ?
>>>> My thinking is no, because KVME_TYPE_SWAP is in fact the correct type;
>>>> I'd opine that it is better to be transparent than make it look like
>>>> there is an OBJT_VNODE object there. It may be that some programs would
>>>> be confused by VNODE info returned on a SWAP type mapping, though I know
>>>> that dtrace handles it OK.
>>> kve_vn_* and kve_path fields are defined only for KVME_TYPE_VNODE kve_type.
>>> So this is in fact a bug in whatever used the API to access kve_path
>>> for KVE_TYPE_SWAP.
>> Hmm, is that documented anywhere? I think it's fair to assume that
>> kve_vn* applies only to the VNODE type,
>> but I know there are several in-tree users that reference kve_path
>> regardless of type (ostensibly relying
>> on the default of an empty string). Maybe one could determine the
>> validity of the kve_vn* fields by
>> inspecting the kve_vn_type (not sure of all the consequences of that)?
>> Or change it to KVME_TYPE_VNODE
>> and deal with the below problem...
> There is no useful documentation for the kern.proc. sysctls.
> My word (and statements from other involved developers) could be
> considered as close to the truth as it can be.
> Somebody taking the efforts to document the stuff would make very
> valuable contribution.

Ok. If I can get a solution figured, I'll plan to include some 
documentation updates.

This problem is somewhat important to me, so I'm going to do some 
additional digging and see if I can't come up with a solution that takes 
into account your notes.

Thanks for the help,
Eric