$ gh repo clone mmlabs-mindmaze/mmlib
$ cd mmlib
$ python3.11 -m venv _e
(_e) $ pip install sphinx sphinx-rtd-theme linuxdoc
(_e) $ meson setup _build
(_e) $ ninja -C _build

Both when trying to generate man pages and when trying to generate HTML documentation, there are many errors of the form

/home/ben/src/mmlib/doc/alloc.rst:4: ERROR: Error in "kernel-doc" directive:
unknown option: "headers".

.. kernel-doc:: src/alloc.c
    :module: alloc
    :headers: mmlib.h
    :functions: mm_aligned_alloc, mm_aligned_free

The documentation build “succeeds” but the individual pages that would have been generated via linuxdoc, e.g. _build/doc/html/alloc.html, have no content, the man page build reports WARNING: no "man_pages" config value nor manual section found; no manual pages will be written, and _build/doc/man3/ is empty.

Am I missing something, or is this no longer working as expected with current versions of sphinx and/or linuxdoc?

Add fstatvfs() and statvfs() like API. List of info useful (among other):

• natural size of block of FS
• free size remaining in volume
• total size of volume

We noticed this when the mmlib package in Fedora Linux started to fail to build from source on Fedora 38, 39 (which is about to be released), and 40 (Rawhide/development). However, I can reproduce it in a fresh git checkout of the current master, f416f7a.

gh repo clone mmlabs-mindmaze/mmlib
cd mmlib
meson setup _build
meson compile -C _build
meson test -C _build --print-errorlogs

[…]
▶ 5/5 - ../tests/socket-api-tests.c:socket:getaddrinfo_valid: Assertion 'rp->ai_socktype == exp_socktype' failed FAIL          
▶ 5/5 - ../tests/socket-api-tests.c:socket:getaddrinfo_error: Assertion 'mm_getaddrinfo("localhost", "ssh", &hints, &res) == -1' failed FAIL          
▶ 5/5 - ../tests/socket-api-tests.c:socket:create_invalid_sockclient: Assertion 'mm_create_sockclient("ssh://localhost:10") == -1' failed FAIL          
5/5 unit api tests        FAIL            11.00s   418/421 subtests passed
>>> LD_LIBRARY_PATH=/home/ben/src/forks/mmlib/_build/src MALLOC_PERTURB_=190 CK_VERBOSITY=silent /home/ben/src/forks/mmlib/_build/tests/testapi
[…]

testlog.txt

I haven’t attempted to dig more deeply into why these might be failing.

In the project xdffileio, we only use the function fcntl with the commands F_GETFL and F_SETFL.
I propose that we write two functions in the mmlib to replace the use of fcntl:

fcntl(fd, F_GETFL) could be replaced by: int mm_getflags (int fd)
-> This function returns the value of the file status flag of fd on success, otherwise returns -1 and errno is set to the appropriate value.

fcntl(fd, F_SETFL, flags) could be replaced by: int mm_setflags(int fd, int flags)
-> Set the file descriptor flags of fd to the value specified by flags. Returns -1 in case of error and errno is set to the appropriate value, otherwise returns 0.

After fixing and/or working around everything in #7, I find that I see a failure like

▶ 5/5 - ../tests/process-api-tests.c:process:wait_signal: Assertion 'status & 0x000000FF == signum' failed: status & 0x000000FF == 5, signum == 4 FAIL          
5/5 unit api tests FAIL            11.33s   419/420 subtests passed

when I build and test mmlib 1.4.2 on Fedora Linux.

This didn’t always fail; I’m not sure what triggered the regression. However, it seems strange to be hard-coding implementation details in the API of a portability library. I’m not sure that the current approach operates at the right level of abstraction. I’m not sure, at a glance, what to propose instead, but I’m happy, upon request, to provide additional information or to test patches.

mmlib documentation generation depends on MindMaze's fork of linuxdoc: https://github.com/mmlabs-mindmaze/linuxdoc
The documentation should be updated to make it known.

Also, let's think about disabling documentation generation by default (and enabling it in the CI instead).

We regularly need to copy file in different project. When this happens, the logic is always the same. If the implementation is available in mmlib, not only it remove boring piece of code from project depending on mmlib, but it also it may open the possibility to use platform specific API to do the copy more efficientlly (like copy_file_range on linux).

To be decided: do we provide API at a level of path, at the level of file descriptors or both...

Consider feasibility and pros/cons of doing so if feasible.