b478f3e737
We document glnx_close_fd as preserving errno, so let's assert that it really does. There are three code paths we need to exercise: 1. fd < 0: glnx_close_fd does nothing, successfully 2. fd >= 0 and close() succeeds 3. fd >= 0 and close() fails The first two are easy, but it's difficult to make close() fail on-demand with only valid code. close(2) documents EIO, but it's difficult to cause an I/O error on-demand. Similarly, close(2) documents ENOSPC and EDQUOT on NFS, but we are unlikely to have a full NFS filesystem available during testing. Instead, we can trigger a failure via the programming error of passing a fd to glnx_close_fd that was already closed, which makes close(2) fail with EBADF. In older libglnx, we wouldn't have been able to test this because it caused an assertion failure, but in GLib and new libglnx it only causes a critical warning, which we can catch and ignore. See also GLib commit GNOME/glib@f1f711dc "tests: Test EBADF and errno handling when closing fds". GLib doesn't have a 1:1 equivalent of glnx_close_fd as public API, but an internal version is used to implement g_autofd. Signed-off-by: Simon McVittie <smcv@collabora.com>
libglnx is the successor to libgsystem.
It is for modules which depend on both GLib and Linux, intended to be used as a git submodule.
Features:
- File APIs which use
openat()like APIs, but also take aGCancellableto support dynamic cancellation - APIs also have a
GErrorparameter - High level "shutil", somewhat inspired by Python's
- A "console" API for tty output
- A backport of the GLib cleanup macros for projects which can't yet take a dependency on 2.40.
Why?
There are multiple projects which have a hard dependency on Linux and GLib, such as NetworkManager, ostree, flatpak, etc. It makes sense for them to be able to share Linux-specific APIs.
This module also contains some code taken from systemd, which has very high quality LGPLv2+ shared library code, but most of the internal shared library is private, and not namespaced.
One could also compare this project to gnulib; the salient differences there are that at least some of this module is eventually destined for inclusion in GLib.
Adding this to your project
Meson
First, set up a Git submodule:
git submodule add https://gitlab.gnome.org/GNOME/libglnx subprojects/libglnx
Or a Git subtree:
git remote add libglnx https://gitlab.gnome.org/GNOME/libglnx.git
git fetch libglnx
git subtree add -P subprojects/libglnx libglnx/master
Then, in your top-level meson.build:
libglnx_dep = subproject('libglnx').get_variable('libglnx_dep')
# now use libglnx_dep in your dependencies
Porting from libgsystem
For all of the filesystem access code, libglnx exposes only
fd-relative API, not GFile*. It does use GCancellable where
applicable.
For local allocation macros, you should start using the g_auto
macros from GLib. A backport is included in libglnx. There are a few
APIs not defined in GLib yet, such as glnx_autofd.
gs_transfer_out_value is replaced by g_steal_pointer.
Contributing
Development happens in GNOME Gitlab: https://gitlab.gnome.org/GNOME/libglnx
(If you're seeing this on the Github mirror, we used to do development on Github but that was before GNOME deployed Gitlab.)