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

[Mauro Carvalho Chehab <mchehab@redhat.com>]

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