Date: Thu, 2 Jan 2014 04:20:59 -0800 From: Stanislav Sedov <stas@freebsd.org> To: Alfred Perlstein <bright@mu.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@FreeBSD.org> 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... Message-ID: <B4329047-629C-4983-BDAE-094476718AFE@freebsd.org> In-Reply-To: <52C54717.5000608@mu.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 2, 2014, at 3:01 AM, Alfred Perlstein <bright@mu.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B4329047-629C-4983-BDAE-094476718AFE>