Date: Wed, 04 Feb 2015 08:25:05 -0600 From: Eric Badger <eric@badgerio.us> To: freebsd-current@freebsd.org Cc: kostikbel@gmail.com Subject: Re: Filepaths in VM map for tmpfs files Message-ID: <54D22BC1.7030202@badgerio.us> In-Reply-To: <20150203203336.GB42409@kib.kiev.ua> References: <54CCEFAB.9040406@badgerio.us> <20150131153621.GH42409@kib.kiev.ua> <54CEE325.4040903@badgerio.us> <20150202093027.GL42409@kib.kiev.ua> <54D0457E.90006@badgerio.us> <20150203203336.GB42409@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54D22BC1.7030202>