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...

[Stanislav Sedov]

On Jan 2, 2014, at 3:01 AM, Alfred Perlstein <bright at 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.
> 
> 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?
> 
> 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.
> 
> 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’d 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’s a pity I have not noticed that before it was merged to 10.x, as I’m 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’t be able to do so (think procstat -f,
procstat -v, fstat).

--
ST4096-RIPE