[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/55663 (Support for EVFILT_USER in kqueue(2))
The following reply was made to PR kern/55663; it has been noted by GNATS.
From: Christos Zoulas <christos%zoulas.com@localhost>
Subject: Re: kern/55663 (Support for EVFILT_USER in kqueue(2))
Date: Fri, 30 Oct 2020 17:42:59 -0400
> 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
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
-----END PGP SIGNATURE-----
Main Index |
Thread Index |