On 30/05/20(Sat) 09:22, Visa Hankala wrote: > On Thu, May 28, 2020 at 12:11:20PM +0200, Martin Pieuchot wrote: > > When it comes to kqueue filters NFS is special. A custom thread is > > created when the first event is registered. Its purpose is to poll > > for changes every 2.5sec. This logic has been inherited from NetBSD > > and is not present in FreeBSD. > > > > Since filt_nfsread() only check `n_size' of a given nfsnode having a > > different context to emulate stat(2) behavior in kernel is questionable. > > So the diff below gets rid of this logic. The rationals are KISS, > > coherency with nfs_poll() and match what other FS kqueue filters do. > > > > While here add a missing write filter. > > > > Matching the nfs_poll() logic and the write filter are necessary to keep > > the current behavior of poll(2) & select(2) once they start querying > > kqfilter handlers. > > I think it is not good to remove nfs_kqpoll(). The function does more > than just supports the read filter. It generates various vnode events. > If the poller is removed, it becomes impossible for example to monitor > an NFS directory with kevent(2).
What do you mean with "impossible to monitor a NFS directory"? Are you saying that NFS being is the only FS to have a specific thread to implement a poller is wanted feature? If it is wanted, why is it NFS only? Which use case involve monitoring a NFS directory with kevent(2)? When are we aware of the existence of a "nfskqpoll" kernel thread? > It is true that the code is not perfect, but having even basic and > best-effort functionality with kevent(2) and NFS is better than nothing > in my opinion. The kqueue subsystem should not dumb down for emulating > poll(2) and select(2). In that case we've to accept or work-around with the fact that a thread is allocated, an operation that can fail, in the kqfilter(). Do you have an opinion on that? What should we do for other FSs is uniformity wanted?
