Hello David, On Fri, 2025-06-13 at 17:26 +0100, David Brownlee wrote: > I think it is generally accepted that this would be a new ABI - a > little similar to MIPS o32 vs n32, but with the twist that all CPUs > support the new ABI and the goal would be for the old ABI to be > entirely replaced. > > If that is the case, the real issue would be how to manage the > coexistence with the existing 2 byte alignment ABI port. > > One option would be to give it a new port name. Sensible if this was a > more mainstream port, but given the limited Debian engineering > resources (waves at glaubitz@), and desire to replace the existing ABI > entirely, I think the effort (and breakage in packages not knowing > about the new cpu name) is probably not warranted.
Exactly. > Given that, I think there are a number of options (of increasing effort): > > 1) Just to build the new ABI port with the same name, and accept that > attempts to run binaries between the two systems will fail without any > specific indication > > 2) Add an ELF note on new ABI binaries (similar to NetBSD/sparc64), > and have the new system fail to run old binaries with a helpful > message I think this is actually a very good idea. Thanks a lot for bringing this up. > 3) Also add a compat layer to the new system to be able to call into a > separate set of abi libs and to versioned system calls (rewriting the > alignment data as needed), similar to NetBSD with it's a.out (2 byte > alignment) to ELF transition (4 byte alignment). That kernel ABI > versioning is likely to be a.... non trivial amount of effort, but > would allow old binaries to run transparently This is also great, but would also require too much engineering effort, I'm afraid. > These stack, so 2) only makes sense if 1) is working, and 3) if 2) is working. > > My understanding is glaubitz@ is working on 1). Assuming that goes > well and unlocks a bunch of additional packages for m68k as expected, > then I think it is worth discussing whether 2) or 3) are needed and > who would work on them. Agreed. > I personally think 2) is definitely worth considering, but as I'm not > volunteering to do the work, my opinion can be taken with a pinch of > salt :-p Yes, I fully agree. It's a great idea which also doesn't require mich effort. > An elephant in the room is "what if the performance hit of 4 byte > alignment is significant". > > In that case some people may want to continue the 2 byte alignment > port (though I think it's safe to say at this point that unless it > reduces the performance to NS32008 leves, glaubitz@ plans to complete > and maintain the 4 byte alignment port). As I said before, the 2 bytes alignment port is pretty much a dead end for Debian, so I don't really see how the performance discussion is helping here. Btw, I don't understand the reference to the NS32008 architecture?! > In that case adding 2) plus the code to detect and reject new ABI > binaries on old systems becomes if anything more interesting, and.... > I'm sure we can look forward to more animated discussions on these > lists... Yes! Thanks a lot for the constructive input. Much appreciated! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
