From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Andy Walls <awalls@md.metrocast.net>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
Jonathan Corbet <corbet@lwn.net>,
linux-media@vger.kernel.org,
sakari.ailus@maxwell.research.nokia.com,
linux-kernel@vger.kernel.org
Subject: Re: What should poll() return when a device is unregistered ? (was "media: Media device node support")
Date: Mon, 22 Nov 2010 17:19:37 +0100 [thread overview]
Message-ID: <201011221719.38369.laurent.pinchart@ideasonboard.com> (raw)
In-Reply-To: <1290430297.2092.16.camel@morgan.silverblock.net>
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
next prev parent reply other threads:[~2010-11-22 16:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1285241696-16826-1-git-send-email-laurent.pinchart@ideasonboard.com>
[not found] ` <201011220035.55615.laurent.pinchart@ideasonboard.com>
[not found] ` <201011221008.06852.hverkuil@xs4all.nl>
2010-11-22 10:41 ` Laurent Pinchart
2010-11-22 11:36 ` Hans Verkuil
2010-11-22 12:51 ` Andy Walls
2010-11-22 16:19 ` Laurent Pinchart [this message]
2010-11-22 23:00 ` Andy Walls
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201011221719.38369.laurent.pinchart@ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=awalls@md.metrocast.net \
--cc=corbet@lwn.net \
--cc=hverkuil@xs4all.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=sakari.ailus@maxwell.research.nokia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®