bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[very WIP PATCH 0/1] Attempt at writing a GHurdFileMonitor for glib


From: Sergey Bugaev
Subject: [very WIP PATCH 0/1] Attempt at writing a GHurdFileMonitor for glib
Date: Tue, 6 Dec 2022 17:48:27 +0300

Hello!

As mentioned in [0], glib is in need of a native Hurd backend for
GLocalFileMonitor. This is what this patch aims to implement. It is *nowhere*
near complete yet, but there should hopefully be already enough things in place
to start gathering feedback, both from the Hurd and glib sides.

[0]: https://lists.debian.org/debian-hurd/2022/03/msg00015.html

A brief overview of the patch:

* gio/hurd is a new directory containing the GHurdFileMonitor implementation,
  just like gio/inotify contains GInotifyFileMonitor and gio/kqueue contains
  GKqueueFileMonitor

* Meson is hooked up to invoke MIG to generate fs_notifyServer.c and
  fs_notify_S.h; it would appear I've 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 messages (in mach_msg_server)

* We're not supposed to use libports, so there's an explicit port set and
  a hashtable. Fortunately glib already has a hashtable implementation (so we
  don't need hurd/ihash) as well as refcounting for GObject-s. Is it fine
  that I only insert the port into the hashtable if
  mach_port_set_protected_payload () fails? In other words, is it legal for
  mach_msg not to pass the protected payload if one has been set for the port?

* We receive {dir,file}_changed_type and attempt to map the it to
  GFileMonitorEvent. The mapping is kind of coarse for now, maybe things could
  be improved here.

* There's something fishy that glibc expects wrt basename/dirname/filename,
  for instance if you watch a single file, it still expects you to pass the
  file basename into g_file_monitor_source_handle_event (), and will ignore
  any events with a non-matching basename, as if you were actually watching
  the parent directory and not that one file. This is probably related to
  inotify semantics or something, I have not looked into this yet. I'd have
  to look into what exactly glib expects and how to emulate that.

* Error handling with abort () is all over the place. I don't know how it's
  supposed to work -- while g_file_monitor () accepts a GError **error
  argument, g_hurd_file_monitor_start () does not. It's unclear where it's
  supposed to propagate errors to.

But despite all the incompleteness and deficiencies, the patch seems to work
somewhat. glib recognizes GHurdFileMonitor as a legitimate type, it gets
picked up as the preferred backend for GLocalFileMonitor, it actually receives
a call to g_hurd_file_monitor_start (), the port manipulation stuff works,
we do get the file_changed message from the translator, and the ::changed
signal does get emitted indeed.

Feedback is very welcome!

Sergey

Sergey Bugaev (1):
  Very WIP: Add GHurdFileMonitor

 gio/giomodule.c             |   4 +
 gio/hurd/fs_notify.defs     |   9 ++
 gio/hurd/fs_notify.h        |  10 ++
 gio/hurd/ghurdfilemonitor.c | 269 ++++++++++++++++++++++++++++++++++++
 gio/hurd/ghurdfilemonitor.h |  43 ++++++
 gio/hurd/meson.build        |  20 +++
 gio/meson.build             |   5 +
 7 files changed, 360 insertions(+)
 create mode 100644 gio/hurd/fs_notify.defs
 create mode 100644 gio/hurd/fs_notify.h
 create mode 100644 gio/hurd/ghurdfilemonitor.c
 create mode 100644 gio/hurd/ghurdfilemonitor.h
 create mode 100644 gio/hurd/meson.build

-- 
2.38.1




reply via email to

[Prev in Thread] Current Thread [Next in Thread]