lkml.org 
[lkml]   [2011]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
    Hello Alan,

    On 03.12.2011 00:19, Alan Cox wrote:
    > On Thu, 1 Dec 2011 15:58:41 +0100
    > HoP <jpetrous@gmail.com> wrote:
    >
    >> Hi,
    >>
    >> let me ask you some details of your interesting idea (how to
    >> achieve the same functionality as with vtunerc driver):
    >>
    >> [...]
    >>
    >>> The driver, as proposed, is not really a driver, as it doesn't support any
    >>> hardware. The kernel driver would be used to just copy data from one
    >>> userspace
    >>
    >> Please stop learning me what can be called driver and what nope.
    >> Your definition is nonsense and I don't want to follow you on it.
    >
    > You can stick your fingers in your ears and shout all you like but given
    > Mauro is the maintainer I'd suggest you work with him rather than making
    > it painful. One of the failures we routinely exclude code from the kernel
    > for is best described as "user interface of contributor"
    >
    > It's a loopback that adds a performance hit. The right way to do this is
    > in userspace with the userspace infrastructure. At that point you can
    > handle all the corner cases properly, integrate things like service
    > discovery into your model and so on - stuff you'll never get to work that
    > well with kernel loopback hackery.

    FWIW, the virtual DVB device we're talking about doesn't have any
    networking capabilities by itself. It only allows to create virtual DVB
    adapters and to relay DVB API ioctls to userspace in a
    transport-agnostic way. Networking already takes place in a separate
    userspace process.

    >> Can you show me, how then can be reused most important part
    >> of dvb-core subsystem like tuning and demuxing? Or do you want me
    >> to invent wheels and to recode everything in the library? Of course
    >
    > You could certainly build a library from the same code. That might well
    > be a good thing for all kinds of 'soft' DV applications. At that point
    > the discussion to have is the best way to make that code sharable between
    > a userspace library and the kernel and buildable for both.

    You could certainly build a library to reach a different goal. The goal
    of vtuner is to access remote tuners with any existing program
    implementing the DVB API.

    One of my primary use cases is to develop DVB API software on my
    notebook, while receiving the data from an embedded device, so I don't
    need an antenna cable connected to my notebook (or don't need to have an
    antenna at my location at all, if an internet connection is available).

    Another use case is to receive data streams over the internet from
    satellite, cable and terrestrial networks that are impossible to receive
    in my area to verify that my DVB API software works with those streams.

    Furthermore, I'd like to use standard tools implementing theDid you even
    unders DVB API, e.g. to scan for channels, to measure signal quality or
    to decode streams on remote locations.

    With vtuner, and an accompanying open source networking daemon, all of
    the above works out of the box. If I'd like to change the way data gets
    relayed between hosts (e.g. add IPv6 or SSL), I'd just need to update
    the userspace client and server.

    With a library, I'd need to implement networking in every little DVB API
    tool I want to use, multiplying the code size of every tool, restricting
    each tool to some arbitrarily chosen network protocol. If I'd like to
    change the way data gets relayed between hosts, I'd need to update every
    application using it.

    >> I can be wrong, I'm no big kernel hacker. So please show me the
    >> way for it. BTW, even if you can find the way, then data copying
    >> from userspace to the kernel and back is also necessery. I really
    >> don't see any advantage of you solution.
    >
    > In a properly built media subsystem you shouldn't need any copies beyond
    > those that naturally occur as part of a processing pass and are therefore
    > free.

    The original version of the vtuner interface makes use of demux hardware
    and also feeds the relevant streams to a/v decoders, in which case you
    cannot avoid copying the MPEG data to kernel space.

    That's also the way to playback local DVB recordings works today without
    vtuners.

    I'm fine with not merging this code, if there are technical arguments
    against it. And personally I don't need it to be merged to be able to
    use it.

    However, Mauro invents half-baked arguments against it, because he fears
    that the code may be "abused" by closed-source userspace drivers (he
    already declared the latter publicly on the linux-media list).

    Unfortunately, I must assume that your own arguments are based on
    Mauro's emails instead of on the source code, because you clearly didn't
    understand the architecture of vtuner, regarding what's supposed to
    happen in kernel space and what not.

    Regards,
    Andreas


    \
     
     \ /
      Last update: 2011-12-03 17:17    [W:0.029 / U:92.784 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site