lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 22 Nov 2010 17:19:37 +0100 From: Laurent Pinchart <laurent.pinchart@...asonboard.com> To: Andy Walls <awalls@...metrocast.net> Cc: Hans Verkuil <hverkuil@...all.nl>, Jonathan Corbet <corbet@....net>, linux-media@...r.kernel.org, sakari.ailus@...well.research.nokia.com, linux-kernel@...r.kernel.org Subject: Re: What should poll() return when a device is unregistered ? (was "media: Media device node support") Hi Andy, On Monday 22 November 2010 13:51:37 Andy Walls wrote: > On Mon, 2010-11-22 at 12:36 +0100, Hans Verkuil wrote: > > On Monday, November 22, 2010 11:41:27 Laurent Pinchart wrote: > > > Hi Hans, > > > > > > On Monday 22 November 2010 10:08:06 Hans Verkuil wrote: > > > > On Monday, November 22, 2010 00:35:54 Laurent Pinchart wrote: > > > > > Hi Jonathan, > > > > > > > > This doesn't really seem to be standardized :-( > > > > > > CC'ing LKML with the question. > > > > > > POLLERR | POLLHUP and POLLERR won't make a difference to select(), but > > > we should still standardize on a poll() return code when devices are > > > unregistered and/or - for hot-pluggable devices - disconnected (for > > > V4L devices unregistered usually means disconnected) ? > > > > Drivers return POLLERR, POLLERR|POLLHUP or POLLHUP in case of a > > disconnect. I'm leaning towards POLLHUP as the most appropriate poll > > return value for a USB disconnect. > > +1 POLLHUP > > http://www.opengroup.org/onlinepubs/009695399/functions/poll.html > > "POLLHUP > The device has been disconnected. [...]" > > > My $0.02 below: > The communication link with the device is closed due to circumstances > that the OS considers normal operation. The OS has, at some level, shut > down its side of the communication link gracefully as well. > > Just because the application or the OS cannot always predict when a USB > disconnect may happen, doesn't mean it is an error. POLLHUP seems to be the best option standard-wise, but it could be a problem for output devices. Applications use the write file descriptors set with select() to wait for a buffer to be ready. Unlike POLLERR, POLLHUP only reports an event on the read file descriptors set. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists