I'd like to suggest extracting an inotify package from fsnotify. It could be greenfield implementation using fsnotify as a reference or involve some actual copy/paste.

It would wrap syscall's InotifyInit and epoll with a idiomatic Go API (e.g. inotify.MovedTo rather than IN_MOVED_TO) for all the Inotify events available on Linux.

Once created, inotify would become a dependency of fsnotify. Fsnotify would be focused on a common cross-platform API and smoothing out the differences between operating systems.

The golang.org/x/sys/unix package doesn't provide integration tests -- a key goal is to have a reliable test suite. Ideally the test suite will be exercised across all architectures that Go supports Linux on by utilizing the Go builders (Go issue golang/go#17312).

NOTE: The same extraction can and should be applied to kqueue and "winfsnotify" in the future. I think it will be most beneficial for inotify, due in part to the number of architectures that Linux supports.

A secondary goal is to fully understand and document the behaviours of inotify without the added layers that fsnotify provides.

I think this would be placed in a separate repository fsnotify/inotify though the issue tracker may be shared (as with the Go project). Inotify would:

• Offer a well-maintained replacement for golang.org/x/exp/inotify for anyone using inotify directly.
• Provide a low-level library that could be used by https://github.com/rjeczalik/notify or other alternatives to fsnotify.
• Becomes a dependency of fsnotify -- though it can be vendored as a internal package of fsnotify if desired. (NOTE: this may impact the old gopkg.in import paths)

Before beginning As part of this endeavour, I think it makes sense to address any open pull requests and open bugs with inotify.

Any volunteers interested in working on this? To proceed, we need enough involvement to have good code review processes in place.