Date: Mon, 19 Jul 1999 12:09:03 +0800 (SGT) From: Vasudha Ramnath <vasu@krdl.org.sg> To: Arun Sharma <adsharma@home.com> Cc: freebsd-hackers@freebsd.org Subject: Re: implementing poll() in a device driver (fwd) Message-ID: <Pine.GSO.4.02.9907191202070.8347-100000@boderek> In-Reply-To: <m3so6p3v4s.fsf@c62443-a.frmt1.sfba.home.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > I have a test driver that returns these values from the poll() function. > > However, the application > > that called the select() is not getting an error. Instead, the select > > is returning that the particular file descriptor is, in this case, > > 'readable' ! > > Take a look at "selscan" algorithm in /usr/src/sys/kern/sys_generic.c > if you wish to learn more. > > Basically, if your driver doesn't implement the poll() functionality, > it can always return 0. This will ensure that select never wakes up > because of a file descriptor associated with your driver. > thanks for your reply. I realise that one can return 0. My point is that if the driver returns POLLERR or POLLHUP, it is not getting handled correctly in sys_generic.c... It seems to me that a positive (non-zero) return value is being interpreted as 'readiness', although there is a comment in sys_generic.c that the backend (driver) can also return POLLHUP or POLLERR. --Vasudha To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.02.9907191202070.8347-100000>