Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver becauseof worrying about possible misusage?

[Mauro Carvalho Chehab]

On 06-12-2011 11:35, Andreas Oberritter wrote:
> On 06.12.2011 14:10, Mauro Carvalho Chehab wrote:
> > On 06-12-2011 10:01, Andreas Oberritter wrote:
> > > On 06.12.2011 12:18, Mark Brown wrote:
> > > > On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote:
> > > > > On 05.12.2011 21:55, Alan Cox wrote:
> > > > > > The USB case is quite different because your latency is very tightly
> > > > > > bounded, your dead device state is rigidly defined, and your loss of
> > > > > > device is accurately and immediately signalled.
> > > >
> > > > > > Quite different.
> > > >
> > > > > How can usbip work if networking and usb are so different and what's so
> > > > > different between vtunerc and usbip, that made it possible to put usbip
> > > > > into drivers/staging?
> > > >
> > > > USB-IP is a hack that will only work well on a tightly bounded set of
> > > > networks - if you run it over a lightly loaded local network it can
> > > > work adequately.  This starts to break down as you vary the network
> > > > configuration.
> > >
> > > I see. So it has problems that vtunerc doesn't have.
> >
> > The vtunerc has the same issues. High latency (due to high loads,  high
> > latency links or whatever) affects it badly, and may cause application
> > breakages if if the device is opened are using O_NONBLOCK mode [1].
>
> O_NONBLOCK doesn't mean that an ioctl must consume zero time. It just
> means that it should return instead of waiting for (more) data to become
> available or writeable.

O_NONBLOCK means (http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html#tag_16_412):


O_NONBLOCK
    When opening a FIFO with O_RDONLY or O_WRONLY set:

        If O_NONBLOCK is set, an open() for reading-only shall return without delay. An open() for writing-only shall return an error if no process currently has the file open for reading.

        If O_NONBLOCK is clear, an open() for reading-only shall block the calling thread until a thread opens the file for writing. An open() for writing-only shall block the calling thread until a thread opens the file for reading.

    When opening a block special or character special file that supports non-blocking opens:

        If O_NONBLOCK is set, the open() function shall return without blocking for the device to be ready or available. Subsequent behavior of the device is device-specific.

        If O_NONBLOCK is clear, the open() function shall block the calling thread until the device is ready or available before returning.

    Otherwise, the behavior of O_NONBLOCK is unspecified.

Basically, syscall should not block waiting for some data to be read (or written).
The ioctl definition defines [EAGAIN] error code, if, for any reason, an
ioctl would block.

Btw, the vtunerc doesn't handle O_NONBLOCK flag. For each DVB ioctl, for example
read_snr[1], it calls wait_event_interruptible()[2], even if the application opens
it with O_NONBLOCK flag. So, it is likely that non-blocking-mode applications
will break.

[1] http://code.google.com/p/vtuner/source/browse/vtunerc_proxyfe.c?repo=linux-driver#75
[2] http://code.google.com/p/vtuner/source/browse/vtunerc_ctrldev.c?repo=linux-driver#420

> Mauro, if the network is broken, any application using the network will
> break. No specially designed protocol will fix that.

A high delay network (even a congested one) is not broken, if it can
still provide the throughput required by the application, and a latency/QoS
that would fit.

> If you want to enforce strict maximum latencies, you can do that in the
> userspace daemon using the vtunerc interface. It has all imaginable
> possibilities to control data flow over the network and to return errors
> to vtunerc.

Yes, you can do anything you want at the userspace daemon, but the
non-userspace daemon aware applications will know nothing about it, and
this is the flaw on this design: Applications can't negotiate what network
parameters are ok or not for its usecase.

> For a DVB API application it doesn't matter whether a tuning
> request fails with EIO because a USB device has been removed, a PCI
> device encountered an I2C error or because the vtuner userspace daemon
> returned an error.

When you go to network, there are several errors that are transitory. For example,
a dropped link may cause the routing protocol (RIP, BGP or whatever) to re-direct
several routes (or, on a LAN, a spanning-tree re-negotiation), causing a temporary
failure to deliver a few packets. All network-based application are written
to consider temporary failures.

This is fundamentally different than an application designed to talk directly with
the hardware, where an error is generally fatal.

> > [1] Btw, if some DVB ioctl currently waits in O_NONBLOCK, this is a POSIX
> > violation that needs to be fixed.
>
> To the best of my knowledge, this doesn't happen.
>
> I think we all realized some days ago that the code is not going to be
> merged upstream anytime in the foreseeable future. You can stop using
> such pointless arguments.

Agreed.

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/