From owner-svn-src-all@FreeBSD.ORG Thu Jan 2 12:21:18 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BFEA146; Thu, 2 Jan 2014 12:21:18 +0000 (UTC) Received: from mx0.deglitch.com (backbone.deglitch.com [78.110.53.255]) by mx1.freebsd.org (Postfix) with ESMTP id 5617514EE; Thu, 2 Jan 2014 12:21:15 +0000 (UTC) Received: from [192.168.1.5] (unknown [37.113.188.80]) by mx0.deglitch.com (Postfix) with ESMTPSA id 922798FC40; Thu, 2 Jan 2014 16:21:04 +0400 (MSK) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: svn commit: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensola... From: Stanislav Sedov In-Reply-To: <52C54717.5000608@mu.org> Date: Thu, 2 Jan 2014 04:20:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201309050009.r8509vsE061271@svn.freebsd.org> <67DFFD7B-01DE-4862-BED3-DD42EB92A8F4@freebsd.org> <20140102093322.GA1655@garage.freebsd.pl> <52C53F69.3040507@mu.org> <20140102104904.GB1655@garage.freebsd.pl> <52C54717.5000608@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1827) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 12:21:18 -0000 On Jan 2, 2014, at 3:01 AM, Alfred Perlstein wrote: > Well I agree strongly with what you are doing except the part where = 9.x jails and earlier are broken because of this change. >=20 > It seems like there is a way out and you agree. Perhaps since the cap = fits in the spare area we can make do for the time being? >=20 > The way to do a major re-org of the kinfo_file/proc/whatever is to = either use libnv as you suggest, check the binary version (as you = suggest) or to make an entirely new one and make the old one = kinfo_file_old and make a new way to fetch the new data as we did with = the various syscalls ostatfs, ostat, etc. >=20 > It still seems like we have a way out that would even give = capabilities another "version" (there are enough cells in _kf_ispare for = the next version of the capabilities code. I agree that we should move to libnv or maybe even something more = structured (like ASN.1 or protobufs) in the future for such usecases to avoid this situation = altogether. I should have looked into doing that much earlier. :( It=92d be really nice if we can avoid this issue by using the spare = fields at the moment, and switch to a new struct/proper serialization by the time we need to = export more capabilities data from the kernel. We actually did exactly that once between 7.x and = 8.x, that is the reason why there is also kinfo_ofile struct in that file as well. It=92s a pity I have not noticed that before it was merged to 10.x, as = I=92m not sure we can do anything about it at the moment. I agree with Pawel that it is = questionable what will lead to more damage. PS: I should also note that the change does not entirely break programs = that deal with proc/filedesc as most of the fields are at the same position. The ones = that need to obtain the file path of a file descriptor won=92t be able to do so = (think procstat -f, procstat -v, fstat). -- ST4096-RIPE