Proposal to improve sysconf()

[xdelatour]

I propose a modification to the sysconf() function in the mintlib library (the kernel is not modified).

The problem with system information is that it is returned:

• either by the sysconf system call (kernel)
• or by the sysconf function (mintlib), which can return it itself or obtain it from the system call
• or by sysctl (kernel)

The goal is to limit ourselves to a systcl backend (since we don't have a complete /proc/sys) in the kernel and to the sysconf function only in the library (sysconf in the kernel is redundant).

Thus,

• the confname.h file (included by unistd.h) contains all possible values ​​for sysconf. It is no longer necessary to duplicate them in the kernel (dos.c)

• The sysconf function returns the information, or retrieves it from sysctl

  • With the exception of _SC_AVPHYS_PAGES, which requires the sysconf system call because sysctl does not provide this value, sysconf can be completely bypassed and deprecated (but should be kept for existing binaries that call it)
  • sysctl can be extended to return the total RAM using totalphysmem(), which will allow obtaining the total number of pages and completely eliminating the need for the sysconf system call

• Maintaining sysconf() only in the mintlib becomes simpler, for when new features are added

• Whether under TOS or MiNT, sysconf can return relevant values ​​(_SC_V8_ILP32_OFF32, which indicates that the system is 32-bit, for example)

• Modern free software can benefit from the availability of information relating to existing features or not on the system (for example, _SC_IPV6)

• Conversely, care must be taken regarding the consequences of automatically enabling or disabling directives via headers in the C library based on the returned results (for example, I made _SC_FSYNC return 0 because the function doesn't do what it's expected to do; we could instead make it return 1 because it exists even if it synchronizes the entire filesystem containing the file in question, perhaps some softwares relies on this information).

• sysconf.c.patch.txt

• confname.h.patch.txt

[mikrosk]

I'm far from being an expert but isn't there the rule there the kernel shouldn't depend on (user-space) mintlib? For the same reason we have duplicates of strcpy etc in libkern.

[xdelatour]

Nothing in the kernel requires sysconf(). It's solely a POSIX function for interoperability

[mikrosk]

Yes but the kernel should be compilable without mintlib installed.

[th-otto]

I agree, the kernel should not depend on mintlib headers. Ie. if we include confname.h in the kernel, and someone detects that confname.h needs some other include first, then that will also be included in the kernel, possibly causing conflicts. And mintlib is changed much more often in this regard.

Regarding _SC_IPV6: do you have any example where software uses it? I find it rather useless, since all the needed defines for IPv6 are missing in the network headers. And adding them is not an option, since then other applications may think that IPv6 is available, but our TCP/IP stack does not support it. So in any case, code that tries to use IPv6 must already be disabled at compile-time.

[xdelatour]

I don't understand what you're saying. The two files I'm suggesting modify the mintlib, not the kernel. How could that make the kernel uncompilable since it doesn't depend on the mintlib?

I did not suggest including confname.h in the kernel. On the contrary, I wrote that the kernel does not need sysconf, which is a POSIX function.

Regarding the IPv6 flag (one example among multiple flags), how could returning 0 (feature not available) trick applications into thinking it's enabled? Returning 0 instead of -1 (undefined) is precisely intended to ensure reliable behavior from compilation scripts instead of errors or unpredictable behavior.

[th-otto]

I did not suggest including confname.h in the kernel.

But you claimed that it would become easier when it is maintained only in mintlib. I understand that such that mintlib's confname.h should be included in the kernel.

On the contrary, I wrote that the kernel does not need sysconf, which is a POSIX function.

No, but the posix sysconf() implementation in mintlib just calls the gemdos Sysconf() function as first try, without even checking the parameter. So the constants in confname.h must match the definitions used in the kernel.

Regarding the IPv6 flag (one example among multiple flags), how could returning 0 (feature not available) trick applications > into thinking it's enabled?

The problem is that the sockaddr_* structures currently are only designed for IPv4, and the ones for IpV6 are not even defined. Some packages do something like ifdef AF_INET6, and if that is defined, later code won't compile. So any IPv6 related code must not make it to the kernel, therefor querying whether IPv6 is available by some other means does not make sense.
And i have never seen anyone doing such a query, at best they use such an ifdef (and sometimes not even that, and the code has to be disabled by patches).