[lkml]   [2011]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Tue, Dec 6, 2011 at 8:36 PM, Mauro Carvalho Chehab
<> wrote:
> On 06-12-2011 12:38, Andreas Oberritter wrote:
>> On 06.12.2011 15:13, Mauro Carvalho Chehab wrote:
>>>     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.

You would need a Data Link Protocol, which would be PPP of some form

I don't think, you have much to negotiate there.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2011-12-06 16:39    [W:0.080 / U:32.380 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site