What is meant by "ABI"?

ProphetOfDoom

ProphetOfDoom

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 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.
 
AlexanderProphet said:
I keep reading that the ABI of FreeBSD is constantly changing.
Click to expand...
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:
Click to expand...
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.
 
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.
 
AlexanderProphet said:
Someone's system has random crashes and someone else says it's that pesky ABI changing again.
Click to expand...
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.
 
Maybe I misremembered. Maybe someone else will chime in?
It's a bit worrying if my brain's manufacturing unfounded rumours about ABIs. :D
 
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.
 
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 ;)
 
  • Like
Reactions: mer
"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.
 
mer said:
"Mirror mirror on the wall, where do kernel syscalls live? KABI or ABI?"
Click to expand...
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.
 
  • Like
Reactions: mer
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.
Click to expand...
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.
 
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.
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top