Mismatch between MiNTLib/FreeMiNT constants

[xdelatour]

I am writing a brief description of SysV functions (pending PR on tos.hyp)

I found a mismatch between the constants used in the MiNTLib and those used in the kernel for the semctl()/Psemctl() cmd parameter.

• MiNTLib uses the same values as glibc and the Linux kernel (11-17)
• FreeMiNT uses the BSD kernel constants (3-9)

The glibc is designed for Linux:
It officially supports the Hurd and Linux kernels
A patch is needed for BSD:
To be compatible with BSD kernel, a lot of patches are applied to the glibc (changes glibc/linux 11-17 to bsd 3-9)
(source: https://en.wikipedia.org/wiki/Glibc#Supported_hardware_and_kernels)

Therefore, when a program includes sys/sem.h, it sends values between 11 and 17 (glibc/MiNTLib) to the kernel (semctl() just calls Psemctl), but the kernel expects values between 3 and 9 (FreeMiNT/BSD).

Two solutions:

• BSD-patch for the glibc: sem.h: values 11-17 (from the glibc) are changed to 3-9 (BSD kernel)
• add glibc/Linux constants 11-17 to the BSD constants 3-9: linux_ipc.h

Of course there is no urgency, but hopefully there are no other such problems in the code.

[mikrosk]

I presume that none of those are actually implemented? I think it makes sense to change the constants to reflect to FreeMiNT expects.

[xdelatour]

I presume that none of those are actually implemented?

That's right, none are implemented.

It is possible to either modify the MiNTLib to use the kernel constants (3-9), or do the opposite by modifying the kernel to use the MiNTLib constants (11-17)

I don't know what makes the most sense. Anyway these constants are totally unused but they must not be in conflict.

[mikrosk]

I'd definitely vote for modifying mintlib. mintlib is glued from various sources, there's no specific reason to maintain glibc compatibility.

[th-otto]

I disagree. mintlib is almost exclusively ported from glibc (just a much older version). Also it could theoretically be the case that some binary was already compiled using the current values, and when you implement them in the kernel using different values, that would give disaster. So if someone is going to implement Psemctl, those values should be changed first to match mintlib.

Another reason is that, whenever something new is implemented, glibc is usually used as a reference.

[xdelatour]

In theory the values could be different but it does not work:
a user program that includes sys/sem.h sends mintlib values (GETZCNT=15) while for kernel GETZCNT=7

I don't have any solution, but we can't maintain mintlib (glibc based), kernel (bsd based) and a patch to make them work together. Even kfreebsd is officially discontinued

I don't plan to implement these functions, but having full documentation of all existing functions will help ensure they work as expected

[th-otto]

That's why i suggested to use the mintlibs values also in the kernel. If you use different values, the mintlib's semctl function would have to map them.

But that is rather hypothetical, as long as the kernels Psemctl function does nothing.