Fix kernel ABI breakage with beta 5.

0001-Fix-kernel-ABI-breakage-with-beta-5.patch

From d79709696d47576eae9df018329aad412411acce Mon Sep 17 00:00:00 2001
From: "Mika T. Lindqvist" <[email protected]>
Date: Sun, 22 Dec 2024 15:18:02 +0200
Subject: [PATCH] Fix kernel ABI breakage with beta 5.

---
 headers/private/system/syscalls.h | 3 ++-
 src/system/kernel/UserTimer.cpp   | 2 +-
 src/system/kernel/fs/fd.cpp       | 2 +-
 src/system/kernel/fs/vfs.cpp      | 2 +-
 4 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/headers/private/system/syscalls.h b/headers/private/system/syscalls.h
index 6501316cc8..b5baa940b0 100644
--- a/headers/private/system/syscalls.h
+++ b/headers/private/system/syscalls.h
@@ -412,7 +412,6 @@ extern status_t		_kern_get_real_time_clock_is_gmt(bool *_isGMT);
 
 extern status_t		_kern_get_clock(clockid_t clockID, bigtime_t* _time);
 extern status_t		_kern_set_clock(clockid_t clockID, bigtime_t time);
-extern status_t		_kern_get_cpuclockid(thread_id id, int32 which, clockid_t* _clockID);
 
 extern bigtime_t	_kern_system_time();
 extern status_t		_kern_snooze_etc(bigtime_t time, int timebase, int32 flags,
@@ -654,6 +653,8 @@ extern status_t		_kern_start_watching_disks(uint32 eventMask, port_id port,
 						int32 token);
 extern status_t		_kern_stop_watching_disks(port_id port, int32 token);
 
+// Syscalls added after beta 5
+extern status_t		_kern_get_cpuclockid(thread_id id, int32 which, clockid_t* _clockID);
 
 // The end mark for gensyscallinfos.
 #ifdef GEN_SYSCALL_INFOS_PROCESSING
diff --git a/src/system/kernel/UserTimer.cpp b/src/system/kernel/UserTimer.cpp
index 50b458ee2a..8a66a154f9 100644
--- a/src/system/kernel/UserTimer.cpp
+++ b/src/system/kernel/UserTimer.cpp
@@ -1526,7 +1526,7 @@ user_timer_get_clock(clockid_t clockID, bigtime_t& _time)
 				_time = thread->CPUTime(false);
 
 				return B_OK;
-			} else if ((clockID & CPUCLOCK_TEAM) == CPUCLOCK_TEAM) {
+			} else {
 				teamID = clockID & CPUCLOCK_ID_MASK;
 				if (teamID == team_get_kernel_team_id())
 					return B_NOT_ALLOWED;
diff --git a/src/system/kernel/fs/fd.cpp b/src/system/kernel/fs/fd.cpp
index bbc8fa1bc9..2cd4ca0e94 100644
--- a/src/system/kernel/fs/fd.cpp
+++ b/src/system/kernel/fs/fd.cpp
@@ -375,7 +375,7 @@ dup2_fd(int oldfd, int newfd, int flags, bool kernel)
 	if (oldfd < 0 || newfd < 0)
 		return B_FILE_ERROR;
 	if ((flags & ~O_CLOEXEC) != 0)
-		return B_BAD_VALUE;
+		flags = 0;
 
 	// Get current I/O context and lock it
 	context = get_current_io_context(kernel);
diff --git a/src/system/kernel/fs/vfs.cpp b/src/system/kernel/fs/vfs.cpp
index 381dd11549..917e3f3ed9 100644
--- a/src/system/kernel/fs/vfs.cpp
+++ b/src/system/kernel/fs/vfs.cpp
@@ -9570,7 +9570,7 @@ _user_create_pipe(int* userFDs, int flags)
 {
 	// check acceptable flags
 	if ((flags & ~(O_NONBLOCK | O_CLOEXEC)) != 0)
-		return B_BAD_VALUE;
+		flags = 0;
 
 	// rootfs should support creating FIFOs, but let's be sure
 	if (!HAS_FS_CALL(sRoot, create_special_node))
-- 
2.43.0

Haiku do not maintain stable kernel UAPI. Not maintaining Kernel UAPI stability is fundamemtal Haiku architecture decision, like in Windows or MacOS. Haiku is not Linux and you can't run older Haiku system libraries in chroot.

Haiku do not maintain stable kernel UAPI. Not maintaining Kernel UAPI stability is fundamemtal Haiku architecture decision, like in Windows or MacOS. Haiku is not Linux and you can't run older Haiku system libraries in chroot.

Not my own code... That code has been used for over 10 years...

Windows 7 up to early Windows 10 builds used same runtime library, which is Windows' equivalent of libroot.so... After Windows 11 was released, Windows 10 switched over to new runtime library which dropped support and compatibility for Windows 7.

Haiku kernel was written by former Be, Inc. employee to be compatible with kernel from BeOS 5, which contradicts with your statement about not having stable userland-kernel ABI (aka syscall ABI). There is no separate syscall header for 32-bit and 64-bit versions of Haiku, so even 64-bit Haiku has to have same syscall numbers.

Each Haiku revision doesn't make a new "version" of system libraries. Every revision up to eventual release of Haiku R1 is still same version.

As mentioned on earlier, it's possible to add new syscalls without breaking compatibility with previous revisions and it's less effort than rebuilding every package current Haiku revisions use as there is circular dependencies that require building some packages more than once.

As I mentioned on Haiku IRC channel, whole purpose of using older headers and libraries during building the packages is to avoid the need to rebuild packages that can't be built on Haiku (beta 5 or subsequent nightly builds before R1 or later betas and release candidates) itself. Like mentioned by others, this does mean different libroot revision is used for linking and running the binaries, thus requiring some level of compatibility on the exported functions and symbols. At this stage, it has nothing to do with the interface between libroot.so and the running kernel, libroot.so compatible with running kernel should be used only when running any created binaries (separation between /boot/system/lib and /boot/system/develop/lib already allows this).

Windows 7 up to early Windows 10 builds used same runtime library, which is Windows' equivalent of libroot.so...

But it have separate syscall numbers so you can't use ntdll.dll from one release in another. See: https://j00ru.vexillium.org/syscalls/nt/64/ .

Haiku kernel was written by former Be, Inc. employee to be compatible with kernel from BeOS 5, which contradicts with your statement about not having stable userland-kernel ABI (aka syscall ABI).

NewOS kernel was never compatible with BeOS syscalls.

Windows 7 up to early Windows 10 builds used same runtime library, which is Windows' equivalent of libroot.so...

But it have separate syscall numbers so you can't use ntdll.dll from one release in another. See: https://j00ru.vexillium.org/syscalls/nt/64/ .

Having separate syscall numbering isn't issue as long as there is no overlap with same number used for different syscalls. When functions are added to runtime, the syscall number must be higher than the last one used on previous revision.

Haiku kernel was written by former Be, Inc. employee to be compatible with kernel from BeOS 5, which contradicts with your statement about not having stable userland-kernel ABI (aka syscall ABI).

NewOS kernel was never compatible with BeOS syscalls.

Neither is Haiku kernel 100% compatible with BeOS 5 kernel, but the compatibility is closer to 100% than 0%... My point was that comparing to Windows isn't relevant as you can compile and use programs and drivers for Windows 7 with years newer Windows release without getting crashes.

My point was that comparing to Windows isn't relevant as you can compile and use programs and drivers for Windows 7 with years newer Windows release without getting crashes.

The same for Haiku and it do not require to have compatible syscall numbers. Compatibility is maintained on system library symbol names level, not syscall level.

The same for Haiku and it do not require to have compatible syscall numbers. Compatibility is maintained on system library symbol names level, not syscall level.

This isn't about Haiku kernel, this is about what limitations or restrictions using packagefs and package_daemon impose on Haiku's runtime. This isn't even about why people NEED TO use nightly builds to compile something for Beta 5 +113, +122 or +125 revisions.

I've used and contributed to Haiku since it was still called OpenBeOS and for the first weeks I worked on kernel and the drivers. There was zero issues before packagefs was introduced. Requiring consistent state is another limitation imposed by package_daemon not Haiku kernel, but in normal world, the state is unlikely consistent due to used packages not being rebuilt for every single Haiku revision and requiring several versions of for example OpenSSL library. Even more likely when actually rebuilding affected packages.