From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 14:25:18 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A519A2D for ; Wed, 4 Feb 2015 14:25:18 +0000 (UTC) Received: from sasl.smtp.pobox.com (pb-smtp1.int.icgroup.com [208.72.237.35]) by mx1.freebsd.org (Postfix) with ESMTP id DA0FAD92 for ; Wed, 4 Feb 2015 14:25:17 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id AC1B833645; Wed, 4 Feb 2015 09:25:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=CUgpV+6HCLiP f/9Dl9UhM4pQvBs=; b=RRMprvPCF8aoOmMYZnsaAq+E59VK4wp6JpKshTrlld4g B89Ap3b9H8PJog/fAKvuQgHIV4jw+waQ5CO2yfhxNNoGw1tQ55z7ygOXoKdokHhv 3UBax/ldBNWSbgTAPyZ5CMzcD8SQI4wrDtSQnUiqZ0q87mhKxE8fKDcxF1iZ+g8= Received: from pb-smtp1.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 965DA33644; Wed, 4 Feb 2015 09:25:10 -0500 (EST) Received: from [192.168.1.103] (unknown [73.164.1.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 0C16133643; Wed, 4 Feb 2015 09:25:09 -0500 (EST) Message-ID: <54D22BC1.7030202@badgerio.us> Date: Wed, 04 Feb 2015 08:25:05 -0600 From: Eric Badger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Filepaths in VM map for tmpfs files 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> In-Reply-To: <20150203203336.GB42409@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 9FE23802-AC79-11E4-A630-7BA29F42C9D4-46178211!pb-smtp1.pobox.com Cc: kostikbel@gmail.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 14:25:18 -0000 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