# What is meant by "ABI"?



## ProphetOfDoom (Aug 19, 2022)

I keep reading that the ABI of FreeBSD is constantly changing. Does the term refer to this:






						System V ABI - OSDev Wiki
					






					wiki.osdev.org
				




?
And in particular, calling conventions (how to use the registers and the stack)?
Because, I always thought this was fairly "fixed" - I've ported assembly programs between Linux and macOS for a long time and I've never had to worry about differing calling conventions AFAICR.
Thanks.


----------



## zirias@ (Aug 19, 2022)

AlexanderProphet said:


> I keep reading that the ABI of FreeBSD is constantly changing.


Where do you read this? The ABI never changes for the whole lifetime of a major release. And even after that, older ABIs are still (optionally, but included in the GENERIC kernel) supported.


AlexanderProphet said:


> Does the term refer to this:


Something like this is part of it. Speaking about the "ABI" of FreeBSD, it not only includes calling conventions, but also all the syscalls. In a nutshell, everything a user-space binary needs to work and interact with the operating system correctly.


----------



## ProphetOfDoom (Aug 19, 2022)

I'm sure I've read it on here several times. Someone's system has random  crashes and someone else says it's that pesky ABI changing again.
Thanks for clarifying anyway.


----------



## zirias@ (Aug 19, 2022)

AlexanderProphet said:


> Someone's system has random crashes and someone else says it's that pesky ABI changing again.


The only thing I could relate that to would be "in-kernel" ABI (which is a different thing). It should be stable as well, but often enough, there's the problem that a kernel module compiled on e.g. 13.0 won't work correctly on 13.1. But this effect will only ever hit kernel modules, never userspace applications.

Well, as long as we're not speaking about -CURRENT of course.


----------



## ProphetOfDoom (Aug 19, 2022)

Maybe I misremembered. Maybe someone else will chime in?
It's a bit worrying if my brain's manufacturing unfounded rumours about ABIs.


----------



## mer (Aug 19, 2022)

I think one needs to make a distinction between ABI (application binary interface) and KABI (kernel application binary interface)  basically what zirias@ is saying in #4.
An application, what does it use?
Typically, libraries.  Standard libraries like libc, libc++, plus a whole bunch in base.  These shouldn't change much or if they do, slowly.  Imagine getting a mysql crash because of a libc change (really doesn't happen or if it does not very often).
KABI may be more in flux;  -CURRENT one could argue "thats the job of current".  Others, shouldn't be much change by design in the release process but it does happen once in a while.
The project "guarantee"  is roughly ABI stays constant for a release, say 13.0-RELEASE, minor changes for 13.1-RELEASE, KABI should stay the same for that (but things like drm-kmod gives a little lie to that).
-CURRENT is "best effort" for both, but if you are running -CURRENT you already know this.

Above is all my understanding of what's been written and come out on different mailing lists/forums.


----------



## zirias@ (Aug 19, 2022)

mer, it is a _bit_ more restrictive. First, you're right, all the libs from base are relevant as well which I forgot to mention, but _also_ all of the kernel's syscalls (cause any user-space binary is always allowed to invoke them directly). And this is _guaranteed_ not to change for the whole lifetime of a major release. Otherwise, having just one package repository per major release (and architecture) would never work.

Indeed, for "in-kernel", it's more a "_should_" in practice


----------



## mer (Aug 19, 2022)

"Mirror mirror on the wall, where do kernel syscalls live?  KABI or ABI?"

 
Yep lots of different pieces, some falling into gray areas between, but always fun.
For the record, doing updates, I personally have never run into what I would call ABI issues.  From source?  You should be rebuilding everything anyway (base and ports).  Binaries?  Maybe if your base is EoL and behind what packages are (say running 13.0-RELEASE and pkgs are 13.1-RELEASE)

So the original question is a good one but as an end user if you are careful and aware of what different versions are around you should be good.


----------



## zirias@ (Aug 19, 2022)

mer said:


> "Mirror mirror on the wall, where do kernel syscalls live? KABI or ABI?"


I'm not sure whether KABI is really unambiguous, that's why I use "in-kernel" to make clear what I mean when talking about changes hitting _kernel modules_.

Syscalls are arguably the most important OS-specific part of the ABI, as they must be present in the running kernel. You can have a look here to see what's included in the GENERIC kernel by default: https://cgit.freebsd.org/src/tree/sys/amd64/conf/GENERIC?h=releng/13.1#n61

Libraries OTOH could be installed from packages. That's offered for compatibility with older major releases (see misc/compat11x and similar ports). Of course, for the currently running major release, the guarantee that ABI won't change includes the libs.


----------



## shkhln (Aug 19, 2022)

AlexanderProphet said:


> Because, I always thought this was fairly "fixed" - I've ported assembly programs between Linux and macOS for a long time and I've never had to worry about differing calling conventions AFAICR.
> Thanks.


ABI means every little detail about machine representation of public interfaces. That doesn't include just calling conventions — available syscalls/functions; the number, type and meaning of their arguments; types of returned values; number, order and size of struct fields (unless those are _opaque_ structs, which is strictly a documentation term, by the way) and whatever else is there (C++ exceptions?) — everything there counts as ABI.

Note, this is almost the same as API, the difference is that one term is for the source code compatibility and the other one is concerned with compiled programs. For example, let's say we have program initializing a struct _foo { bar, baz}_, which we pass to the function _xyz(foo)_ in a separate shared/static library. If we change the field order to _foo { baz, bar}_, we don't have to touch anything else in the source code, but the program _and_ the library would have to be recompiled. If we only recompile only one of them, they will be very confused. That's the same API, but essentially two different ABI versions.


----------



## cy@ (Aug 19, 2022)

zirias@ said:


> The only thing I could relate that to would be "in-kernel" ABI (which is a different thing). It should be stable as well, but often enough, there's the problem that a kernel module compiled on e.g. 13.0 won't work correctly on 13.1. But this effect will only ever hit kernel modules, never userspace applications.
> 
> Well, as long as we're not speaking about -CURRENT of course.


The in-kernel ABI, called the KBI, does change. However most of it is pretty much static these days except for the LinuxKPI module, which supports drm-510-kmod and iwlwifi(4). There has been significant development in both areas already this year.

When the KBI or ABI change __FreeBSD_version is typically bumped.


----------



## mer (Aug 19, 2022)

cy@ said:


> When the KBI or ABI change __FreeBSD_version is typically bumped.


This is a very important point.  When building ports, version is checked.


----------

