On Thu, Sep 09, 2021 at 12:01:14PM -0600, Theo de Raadt wrote:
> Stuart Henderson <s...@spacehopper.org> wrote:
>
> > On 2021/09/09 06:47, Greg Steuck wrote:
> > > Mark Kettenis <mark.kette...@xs4all.nl> writes:
> > >
> > > >> From: "Theo de Raadt" <dera...@openbsd.org>
> > > >> Date: Tue, 07 Sep 2021 07:08:19 -0600
> > > >>
> > > >> Or we could coordinate the Greg approach as a sysctl ABI change near a
> > > >> libc major bump. On the other side of such a bump, all kernel + base +
> > > >> packages are updated to use the new storage ABI. We get orderly .h
> > > >> files without a confusing glitch, and kern_sysctl.c doesn't need to
> > > >> store the value into two fields (32bit and 64bit) for the forseeable
> > > >> future.
> > > >>
> > > >> Over the years I've arrived at the conclusion that maintaining binary
> > > >> compatibility at all costs collects too much confusing damage.
> > > >> Instead,
> > > >> we've built an software ecosystem where ABI changes are expected and
> > > >> carry minimal consequence.
> >
> > Sadly rust and especially go made a different decision about that.
>
> I don't understand why this matters.
>
> 3 libraries are cranking tomorrow. For binary compatibility, people must
> upgrade their packages.
>
> As to the binaries they built by hand? Shrug!
>
Speaking for Rust (which I know better, but I could easily assume Go
did the same), developers easily assumes that the world is Linux, and
backward compatibility is mandatory everywhere.
I had hard time to explain to them (1) that ABI and API could break on
platforms where they expects it wouldn't (like Windows), and that it
exists platforms where ABI/API breaking are normal (like BSDs).
Rust built lot of code on this (wrong) assumption. The simplier
example is the rust libc crate (2), which is a one time translation in
Rust language of libc headers. The difficulty is you can't easily
update definitions in breaking ways (3), because it isn't expected to
happen.
So for us, it means we have to deal with broken definitions in ports
and maintain local patches. But please don't missread me: I am not
asking for not doing breaking changes. I am just explaining why it is
matter a bit: the transition might not be free for ports
developers. It just need some synchronization to measure the potential
impact and prepare patches if need (like we already do for several
changes in base).
Regarding Rust, a badly prepared transition could impact more than
2000 ports, so ~20% of ports for amd64, with runtime breakages.
$ show-reverse-deps lang/rust | wc -l
2091
This particular change on vm_dsize is not expected to have such impact
for Rust programs. It should even be free as Rust libc crate doesn't
have `struct kinfo_proc` definition. I can't comment on Go side.
Thanks.
(1) Extend Rust target specification to follow more closely LLVM triple
specification.
The underlined purpose is to allow Rust compiler to target more easily BSD
OS version.
https://github.com/semarie/rust-rfcs/blob/target-extension/text/0000-target-extension.md#motivation
https://github.com/rust-lang/rfcs/pull/2048
(2) How to deal with breaking changes on platform ? [BSDs related]
https://github.com/rust-lang/libc/issues/570
(3) List of libc issues labels as "breakage-candidate"
https://github.com/rust-lang/libc/labels/breakage-candidate
--
Sebastien Marie
