Hi, is anyone working on implementing the following linux syscalls? memfd_create() inotify_init() inotify_init1() There's Linux binary-only software which seems to require it.
(In reply to Bjoern A. Zeeb from comment #0) Heh, we just implemented memfd_create in terms of shm_open2. I'll take a look at implementing the Linux syscall version- it should be fairly simple now that we implement everything it needs.
A commit references this bug: Author: kevans Date: Mon Jun 29 03:09:16 UTC 2020 New revision: 362769 URL: https://svnweb.freebsd.org/changeset/base/362769 Log: linuxolator: implement memfd_create syscall This effectively mirrors our libc implementation, but with minor fudging -- name needs to be copied in from userspace, so we just copy it straight into stack-allocated memfd_name into the correct position rather than allocating memory that needs to be cleaned up. The sealing-related fcntl(2) commands, F_GET_SEALS and F_ADD_SEALS, have also been implemented now that we support them. Note that this implementation is still not quite at feature parity w.r.t. the actual Linux version; some caveats, from my foggy memory: - Need to implement SHM_GROW_ON_WRITE, default for memfd (in progress) - LTP wants the memfd name exposed to fdescfs - Linux allows open() of an fdescfs fd with O_TRUNC to truncate after dup. (?) Interested parties can install and run LTP from ports (devel/linux-ltp) to confirm any fixes. PR: 240874 Reviewed by: kib, trasz Differential Revision: https://reviews.freebsd.org/D21845 Changes: head/sys/amd64/linux/linux_dummy.c head/sys/amd64/linux32/linux32_dummy.c head/sys/arm64/linux/linux_dummy.c head/sys/compat/linux/linux.c head/sys/compat/linux/linux.h head/sys/compat/linux/linux_file.c head/sys/compat/linux/linux_file.h head/sys/i386/linux/linux_dummy.c
I'm facing the problem as Bjoern. I have a closed source Linux binary that calls inotify_* functions. We do have libinotify-kqueue - a usermode library that implements inotify interface in terms of kevent/kqueue one. However, there seem to be no way to easily hook it into Linuxulator, because inotify_* are syscalls on Linux.
(In reply to Gleb Popov from comment #3) (In reply to Gleb Popov from comment #3) hmm, I'll take a look at the libinotify-kqueue library code, I suspected that it was not so easy to implement inotify* on top of the kqueue/kevent, however someone did it. Could you please check 228115?
(In reply to Gleb Popov from comment #3) Hi Gleb, Did you try with the instructions at https://github.com/libinotify-kqueue/libinotify-kqueue under "Building under linuxolator (FreeBSD 13+)"?
(In reply to Fernando Apesteguía from comment #5) Oh, I didn't think the preloading trick will work for these functions. Thanks for the hint, I'll keep this in mind.
(In reply to Gleb Popov from comment #6) Are you saying your app statically linked to libc, or makes direct inotify_* system calls without going through libc?
(In reply to Damjan Jovanovic from comment #7) Not sure about direct syscalls, but it is certainly linked to libc dynamically. I believe preloading is a way to go.
(In reply to Fernando Apesteguía from comment #5) I see that libinotify is already Ports and available as a package. Would it be possible to also have something like linux-c7-libinotify so it is more easily installable?
FWIW, NetBSD seems to support inotify for their Linux compat now.
(In reply to Edward Tomasz Napierala from comment #10) Aha, it was done by Theodore Preduta as part of GSoC 2023. https://www.pta.gg/projects/gsoc/
^Triage: mark as In Progress since there has been a commit. Is there still anything that needs to be done on this PR?
(In reply to Mark Linimon from comment #12) Implementing inotify in kernel is a lot of work and I think it requires a similar infrastructure for the kevent facility first. No one it working on it AFAIK, so this PR is certainly not "In Progress". A workaround is available by preloading the libinotify-kqueue usermode library compiled for Linux. This can be streamlined by creating a proper port for it, I think.
FWIW I have been working on a native inotify implementation. It works well enough to run test programs, there is still a fair bit of integration left to do, and there are some compatibility issues involving the name cache which will be hard to fully fix. There are some fundamental race conditions in EVFILT_VNODE which make it unusable for some purposes, so building inotify on top of kevent(EVFILT_VNODE) doesn't really help me, hence the native implementation. For example, suppose some service creates files in a directory, and I want a notification when that service is done with a file. With inotify, I can track the directory with IN_CLOSE. With EVFILT_VNODE, I need to 1) watch the directory for writes, 2) when a write occurs, scan the directory to find new files, 3) open new files and wait for NOTE_CLOSE. But if the service closes the file before step 3, I miss the notification. I do not see how this can be solved without a new notification interface. Originally I implemented a new kqueue filter, EVFILT_FSWATCH, which gives notifications for all filesystem, kind of like MacOS' fsevents. But I think it is probably more useful to have a Linux-compatible inotify instead, so I will go ahead with that. I would like to integrate this into the linuxulator, if only so that I can run the LTP inotify test programs. If anyone has done this recently and can describe the steps, I'd greatly appreciate it; I've found devel/linux-ltp, but it fails to fetch.
(In reply to Mark Johnston from comment #14) > I do not see how this can be solved without a new notification interface. The situation with directory watching you described is one of the largest problems with kevent-based FS monitoring. I completely agree that the "real" implementation shouldn't be based on kevent. We have a kevent-based implementation in usermode which started to work as good as it is possible with the "direct" mode [1]. I'm now pushing it to major inotify consumers like glib and KDE and the feedback is positive. [1] https://github.com/libinotify-kqueue/libinotify-kqueue/commit/c3dff3863e386b7f0cdea98c44d92e2ee66e5a35
(In reply to Mark Johnston from comment #14) > I've found devel/linux-ltp, but it fails to fetch. https://distcache.FreeBSD.org/ports-distfiles/centos/ltp-20200605.b54247721-368.1.x86_64.rpm I haven't determined why, but for some reason, the port is trying to fetch and install the (non-existant) i686 version. If you add this hack to the Makefile for devel/linux-ltp the port fetches and installs. EXTRACT_SUFX_i386=.x86_64.rpm
A native inotify implementation and mailing list post: https://lists.freebsd.org/archives/freebsd-hackers/2025-May/004517.html https://reviews.freebsd.org/D50315