Skip to content

Draft: GHurdFileMonitor

Sergey Bugaev requested to merge bugaevc/glib:hurd-file-monitor into main

As mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008208, GLib has removed the fam/gamin file monitor backend in !2570 (merged), leaving GNU/Hurd without a working file monitor backend implementation (save for GPollFileMonitor).

!2570 (merged) mentions:

FAM might still be used on some commercial Unix distributions, but there are no contributors from those distributions, and certainly no CI for them to prevent regressions.

But GNU/Hurd is not a commercial Unix, there are people who care about glib working great on GNU/Hurd, and we want to set up CI to make sure it keeps building and working.

This MR adds a Hurd-specific file monitoring backend, GHurdFileMonitor, alongside the existing inotify, kqueue, and win32 backends. This class uses Hurd's native file change notification mechanism, namely the file_notice_changes (), dir_notice_changes (), file_changed (), dir_changed () RPCs as defined in Hurd's fs.defs and fs_notify.defs.

Implementation notes:

  • Meson is hooked up to invoke MIG to generate fs_notifyServer.c and fs_notify_S.h; looks like I've even managed to do this without having to hardcode the full path to /usr/include/i386-gnu/hurd/fs_notify.defs.
  • There's a separate, implicitly spawned thread (GThread) that waits on incoming Mach messages in mach_msg_server ().
  • We're not supposed to use libports as Hurd servers typically do, so there's an explicit port set and a hashtable. Fortunately glib already has a hashtable implementation as well as refcounting for GObjects, and things map to the glib concepts quite naturally.

Since not all Hurd translators (filesystem implementations) support the {file,dir}_notice_changes / fs_notify interface, the implementation attempts to fall back to polling (GPollFileMonitor) if a particular translator refuses the request for notifications. For this, the first commit of the two introduces fallibility into GLocalFileMonitorClass.start, which lets the implementation propagate its errors upwards.

This MR is a draft for now, because:

  • while things seem to mostly work, more real-world testing is needed, with e.g. GTK-based file managers;
  • there are still some TODOs in the code, also it would be nice to improve thread safety somewhat;
  • the file monitor tests don't pass;
  • as I've been told, the platforms policy requires CI to be in place for kernel-specific code to be merged.

As for the tests not passing: these tests seem to check for a very specific set of events being emitted by a file monitor in several scenarios. The tests are just skipped on win32 (with g_test_skip ("FIXME, test is broken on win32");), and there's a mechanism in the test to account for the differences in how events are emitted by the other two existing backends, inotify and kqueue.

Given the apparent differences between what existing backends emit, I'm leaving towards adding another set of quirks to the test to account for the differences of this Hurd file monitor implementation. But it would also make sense to try harder to match the events that the inotify backend is emitting.

cc @pwithnall, @sthibaul, @zamaudio

Merge request reports