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

[Andreas Oberritter]

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.

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

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. 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.

> [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.

Regards,
Andreas
--
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/