Message-ID: <4EDE2F61.301@redhat.com>
Date:	Tue, 06 Dec 2011 13:06:09 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Andreas Oberritter <obi@...uxtv.org>
CC:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, HoP <jpetrous@...il.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because
 of worrying about possible misusage?

On 06-12-2011 12:38, Andreas Oberritter wrote:
> On 06.12.2011 15:13, Mauro Carvalho Chehab wrote:
>> O_NONBLOCK
>>      When opening a FIFO with O_RDONLY or O_WRONLY set:
>                       ^^^^ This does not apply.
>
> [...]
>
>>      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.
>
> This is the important part:
> - It specifies the behaviour of open(), not ioctl(). I don't see a
> reason why open should block with vtunerc.
> - Read again: "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).
>
> That's because open() does not read or write.
>
>> The ioctl definition defines [EAGAIN] error code, if, for any reason, an
>> ioctl would block.
>
> Fine.
>
>> 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.
>
> Of course, read operations must wait until the value read is available
> or an error (e.g. timeout, i/o error) occurs. Whether it's an i2c
> transfer, an usb transfer or a network transfer doesn't make a
> difference. Every transfer takes a nonzero amount of time.

Yes, posix is not 100% clear about what "non block" means for ioctl's, but
waiting for an event is clearly a block condition. This is different than
doing something like mdelay() (or even mleep()) in order to wait for an
specific amount of time for an operation to complete.

A vtunerc => daemon => network transfer =>daemon => vtunerc is a block condition,
as the network may return in a few ms or may not return and a long
timeout at the daemon would give an error. Also, as the daemon may be swapped
to disk (as the daemon runs on userspace), this may even involve other
blocking operations at the block layer.

> As Honza already demonstrated, in a typical LAN setup, this takes only
> few milliseconds, which with fast devices may even be faster than some
> slow local devices using many delays in their driver code.
>
> If an application breaks because of that, then it's a bug in the
> application which may as well be triggered by a local driver and thus
> needs to be fixed anyway.

It is not a bug in the application. It requested a non-block mode. The driver
is working in block mode instead. It is a driver's bug.

>>> 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.
>
> Then neither vtunerc nor any other application will break. Fine.
>
>>> 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.
>
> How do you negotiate network parameters with your ISP and all involved
> parties on the internet on the way from your DSL line to some other
> peer? Let me answer it: You don't.

TCP flow control mechanisms, RSVP, MPLS, IP QoS flags, ICMP messages, etc.

>>> 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.
>
> I seriously doubt that, unless "consider" means "print an error and
> exit" or "all" means "some".
> Anyway, such temporary failures can be handled by the userspace daemon.
>
>> This is fundamentally different than an application designed to talk
>> directly with
>> the hardware, where an error is generally fatal.
>
> Fatal or not, if you return a temporary error code like EAGAIN, for
> example, that's not the case.
>
> Do you recommend applications to just die if an ioctl fails?

Network applications (Youtube, Skype, mplayer, you name it) have
mechanisms to handle high delays, congestion, etc. Cheating with a non-network
application to work via the network is not the same as a network-based application.
You'll never achieve the same result. Only if the network is close to a
"pure wire" (e. g., no congestion, no packet loss, etc), such solution
works.

> Btw.: How do you handle firmware uploads via I2C in non-blocking mode?
> Should applications always fail if a firmware upload that takes longer
> than some ms, e.g. when tuning to a different delivery system or when
> the firmware is yet to be loaded before the first ioctl may run?

The right thing to do is to return -EAGAIN for all syscalls while the firmware
is not loaded. Unfortunately, several driversdon't do the right thing.

Regards,
Mauro.
--
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