On 09/06/20(Tue) 11:26, Mark Kettenis wrote: > > Date: Tue, 9 Jun 2020 11:04:02 +0200 > > From: Martin Pieuchot <[email protected]> > > > > On 20/05/20(Wed) 14:22, Martin Pieuchot wrote: > > > On 20/05/20(Wed) 12:28, Mark Kettenis wrote: > > > > > Date: Wed, 20 May 2020 11:42:32 +0200 > > > > > From: Martin Pieuchot <[email protected]> > > > > > > > > > > Diff below fixes an incoherency between poll(2) and kqueue(2) when it > > > > > comes to non-character devices. It makes spec_kqfilter() behaves like > > > > > spec_poll(): returns "true" when applied to any non-character device. > > > > > > > > > > ok? > > > > > > > > That is a change in behaviour. What do other BSDs do in this case? > > > > > > By reading code I figured out that: > > > - NetBSD only calls the kqfilter handler for character devices and > > > returns EOPNOTSUPP otherwise. > > > > > > - FreeBSD doesn't allow opening block devices in devfs_open(), so > > > only character devices seem to support poll(2) and kqueue(2). > > > > > > - I couldn't find a difference between block and character devices > > > handling in DragonFlyBSD, it seems that the underlying kqfilter > > > handler is always called. > > > > > > > I think the new behaviour makes sense, but it could reveal some nasty > > > > bugs in cases where code accidantily uses kqueue(2) with a file > > > > descriptor for a block device. > > > > > > The alternative I could think of was changing the existing poll handler > > > to do selfalse() instead of seltrue(). However this makes it very hard > > > to figure out a regression. On the other hand, assuming that a block > > > device is always ready to be read via kqueue(2) seems to have a low > > > impact. > > > > Updated diff that considers the new EV_OLDAPI flag and fallbacks to > > seltrue_kqfilter() if it is set. > > > > This flag is kernel-only an intended to be set by the new poll(2) and > > select(2) implementations. This way kevent(2) keeps its current > > behavior. > > > > While here change cttykqfilter() in the same way. > > > > ok? > > I think EV_OLDAPI is a really weird name for this. And if it is > kernel-only, should it have a double-underscore in front of it to > signal it is not to be used in userland? Maybe __EV_SELECT or > __EV_POLL would be a better name for this?
Sure, I'm happy to do the rename. > I'm not sure the controling tty device behaviour is actually sensible, > but it is retaining the status quuo which is what you want at this > point. Exactly. Is that an ok?
