[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
- [very WIP PATCH 0/1] Attempt at writing a GHurdFileMonitor for glib,
Sergey Bugaev <=