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

    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.029 / U:4.452 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site