On 30/05/20(Sat) 15:49, Visa Hankala wrote: > [...] > Local filesystems can observe changes at the source, which makes polling > unnecessary. NFS clients do not have that benefit. The NFSv3 protocol > lacks a mechanism to notify clients of changes. > > The NFS polling mechanism is in use for example when running tail -f > on a remote file. Directory monitoring can be utilized for example > by a directory browser application or a distributed batch processing > system. > > > > 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? > > Can't the emulation of poll(2) and select(2) operate without the poller? > These system calls are supposed to return true for regular files for > reading and writing. No polling of remote state is needed for that. > > The read behaviour of poll(2) and select(2) differs from kevent(2)'s > EVFILT_READ. Consequently, there has to be an indicator that makes > f_event work in poll(2)/select(2) mode. I guess the same indicator can > control nfs_kqfilter().
So are you saying that poll(2) is broken on NFS and suggest that I extend the kqfilter to match this behavior?
