FreeBSDFileStat broken under FreeBSD 12

[Freaky]

FreeBSD 12 has a new stat structure, complete with 64-bit inode numbers, link counts, and some field reorderings.

[headius]

We'll need to detect which FreeBSD we're on (or some other way to know which struct to use) and have two definitions, I believe.

[Freaky]

I added a simple version check in acc1d9d, which I guess is better than nothing.

A proper fix would, I suppose, involve knowing which ABI we're running under. The above will break in, say, my 11.2 jail env under 12.0, because os.version is still 12.0 :/

[woodsb02]

The ideal way to detect the ABI would be to read the __FreeBSD_version value.
http://svnweb.freebsd.org/base/head/sys/sys/param.h?view=markup

Values of 1200031 and later have the 64 bit inodes, as shown here:
https://www.freebsd.org/doc/en/books/porters-handbook/versions-12.html

That said, simply detecting it is FreeBSD 12 should be enough for it to work on official releases.

[Freaky]

Does the FFI layer expose symbol information in any way? Could we tell if we've linked to, for instance, lstat@FBSD_1.5?

[ltning]

This leaves, among other things, Puppet(server) broken on FreeBSD 12. I assume it needs fixing here before a new Puppet version can be rolled; what would it take to fast forward this? The change in acc1d9d seems to match for 12.0 only; anything >=12.0 should be matched (until the next change..)

[Freaky]

It's a lexicographic comparison, anything that sorts after 12.0 should be matched too.

If a version check is to be used, it's probably marginally better to use freebsd-version -u to get the userspace version rather than asking Java for the kernel version.

I suspect the best fix is to add dlvsym() support to jnr-ffi/jffi and explicitly try to load known versioned symbols.

[Freaky]

For prior art, this is basically what Rust's libc crate does:

src/unix/mod.rs
562:    #[cfg_attr(target_os = "freebsd", link_name = "fstat@FBSD_1.0")]
569:    #[cfg_attr(target_os = "freebsd", link_name = "stat@FBSD_1.0")]
603:    #[cfg_attr(target_os = "freebsd", link_name = "readdir@FBSD_1.0")]
608:    #[cfg_attr(target_os = "freebsd", link_name = "readdir_r@FBSD_1.0")]
631:    #[cfg_attr(target_os = "freebsd", link_name = "fstatat@FBSD_1.1")]
786:    #[cfg_attr(target_os = "freebsd", link_name = "lstat@FBSD_1.0")]
972:    #[cfg_attr(target_os = "freebsd", link_name = "mknod@FBSD_1.0")]

src/unix/bsd/mod.rs
462:    #[cfg_attr(target_os = "freebsd", link_name = "glob@FBSD_1.0")]
469:    #[cfg_attr(target_os = "freebsd", link_name = "globfree@FBSD_1.0")]

src/unix/bsd/freebsdlike/mod.rs
1088:    #[cfg_attr(target_os = "freebsd", link_name = "kevent@FBSD_1.0")]
1104:    #[cfg_attr(target_os = "freebsd", link_name = "mknodat@FBSD_1.1")]

Pinning them to to FreeBSD's compatibility shims for now.

[ltning]

It's a lexicographic comparison, anything that sorts after 12.0 should be matched too.

Yes, sorry, misread that part.

If a version check is to be used, it's probably marginally better to use freebsd-version -u to get the userspace version rather than asking Java for the kernel version.

Not just marginally better, it's absolutely crucial to use the userspace version vs kernel version as long as you're not reading kernel structures directly. Otherwise it'd "mysteriously" break in the case of, say, a 11.2 jail running on a 12.0 kernel - which we're currently doing to keep puppetserver running. Which is, incidentally, also a very common practice "out there".

[Freaky]

I say marginal because I wasn't sure it'd actually work with an 11 package on a 12 userspace, which is also a common practice. Looks like it should, but it's still a fragile-looking band-aid and not what I'd consider a long-term solution.

[smortex]

I say marginal because I wasn't sure it'd actually work with an 11 package on a 12 userspace, which is also a common practice

This is not supported by FreeBSD. It may happen to work, but we really don't care.

Basically:

• you can have a kernel newer than the userland (because when you upgrade you want to boot in the new kernel in order to update the userland), but a userland newer than the kernel is not supported;
• your packages should match the userland. After upgrading, pkg(8) will complain hardly if it detects that the installed packages or for another version of FreeBSD.

This allows you to have jails with a previous version of FreeBSD (userland) with packages for that previous version of FreeBSD. Only the kernel is newer, and that is supported.

[smortex]

BTW, regarding Java, the .jar file we get at the end should be the same regardless of the environment we build on, right? (I am not used to Java)

So detecting the version of the symbol and using one implementation or the other seems the right way to go, as suggested by @Freaky here #126 (comment)

[Freaky]

This is not supported by FreeBSD. It may happen to work, but we really don't care.

I'd suggest this isn't really a credible position, because it's a major component of almost any system upgrade - you install the new world, reboot, rebuild and reinstall packages, then delete the old libraries they were depending on.

That's a documented process, and it doesn't say "btw all your packages will probably break while you're waiting for it all to rebuild". And it's just as well because it's workflow I've depended on for nearly 20 years.