Re: kern/55663 (Support for EVFILT_USER in kqueue(2))

[Ruslan Nikolaev <nruslan_devel%yahoo.com@localhost>]

The following reply was made to PR kern/55663; it has been noted by GNATS.

From: Ruslan Nikolaev <nruslan_devel%yahoo.com@localhost>
To: Christos Zoulas <christos%zoulas.com@localhost>, gnats-bugs%netbsd.org@localhost
Cc: jnemeth%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/55663 (Support for EVFILT_USER in kqueue(2))
Date: Sat, 31 Oct 2020 23:12:40 -0400

 Thanks Christos and other contributors for taking care of this patch! I 
 assume nothing else is needed from my side.
 
 Btw, a bit off topic, did anyone look at kern/55664 (the next bug 
 report)? There I have a fix for the SMP version of rump kernels, and I 
 can fully explain/justify those changes. There is a race condition there 
 which we encountered while working on our project. In addition, I have 
 some other (small) fixes for rump kernels which I have not posted yet.
 
 On 10/30/20 5:42 PM, Christos Zoulas wrote:
 > I agree!
 >
 > christos
 >
 >> On Oct 30, 2020, at 4:35 PM, John Nemeth <jnemeth%cue.bc.ca@localhost> wrote:
 >>
 >> The following reply was made to PR kern/55663; it has been noted by GNATS.
 >>
 >> From: John Nemeth <jnemeth%cue.bc.ca@localhost>
 >> To: matthew green <mrg%eterna.com.au@localhost>,
 >>         Ruslan Nikolaev <nruslan_devel%yahoo.com@localhost>
 >> Cc: gnats-bugs%netbsd.org@localhost
 >> Subject: re: kern/55663 (Support for EVFILT_USER in kqueue(2))
 >> Date: Fri, 30 Oct 2020 13:31:24 -0700
 >>
 >> On Oct 30, 20:24, matthew green wrote:
 >> }
 >> } just to throw my hat in here as well -
 >> }
 >> } i am interested in a solution for EVFILT_USER support.
 >> } there are many apps that would benefit from it.  (there
 >> } are a few more events like directory updates, close,
 >> } and write in freebsd i'd also like to see added.)
 >> }
 >> } i believe it could live in userspace, and that would be
 >> } strongly preferably, but unless it's actually compatible
 >> } with existing implementations (ie, they just start to
 >> } work without patching beyond "use this freebsd path"),
 >> } it seems not nearly as useful as it should be.
 >>
 >>       We've seen cases where libc is bypassed by major things such
 >> as Rust or Go (I recall one of those having problems due to using
 >> syscalls directly, but I don't recall which one).  If we're going
 >> to be compatible with other BSDs then I strongly believe it has to
 >> be at the syscall level as much as possible and not at the API
 >> level.  For this reason, I believe that it must go in the kernel.
 >>
 >> }-- End of excerpt from matthew green
 >>