Re: [RFC] vtunerc - virtual DVB device driver

From: Markus Rechberger <mrechberger@gmail.com>
To: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: "Devin Heitmueller" <dheitmueller@kernellabs.com>,
	"Andreas Oberritter" <obi@linuxtv.org>, HoP <jpetrous@gmail.com>,
	"Sébastien RAILLARD (COEXSI)" <sr@coexsi.fr>,
	"Rémi Denis-Courmont" <remi@remlab.net>,
	linux-media@vger.kernel.org
Subject: Re: [RFC] vtunerc - virtual DVB device driver
Date: Tue, 21 Jun 2011 19:12:00 +0200	[thread overview]
Message-ID: <BANLkTim12gAKsK7OXMw3eTcEq6ds1cYuYA@mail.gmail.com> (raw)
In-Reply-To: <4E00B1D0.5080101@redhat.com>

2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
> Em 21-06-2011 10:44, Devin Heitmueller escreveu:
>
>> Mauro, ultimately it is your decision as the maintainer which drivers
>> get accepted in to the kernel.  I can tell you though that this will
>> be a very bad thing for the driver ecosystem as a whole - it will
>> essentially make it trivial for vendors (some of which who are doing
>> GPL work now) to provide solutions that reuse the GPL'd DVB core
>> without having to make any of their stuff open source.
>
> I was a little faster to answer to my previous emails. I'm not feeling
> well today due to a strong pain on my backbone.
>
> So, let me explain what would be ok, from my POV:
>
> A kernelspace driver that will follow DVBv5 API and talk with wit another
> device via the Kernel network stack, in order to access a remote Kernel board,
> or a kernel board at the physical machine, for virtual machines. That means that
> the dvb stack won't be proxied to an userspace application.
>
> Something like:
>
> Userspace app (like kaffeine, dvr, etc) -> DVB net_tunnel driver -> Kernel Network stack
>
> Kernel Network stack -> DVB net_tunnel driver -> DVB hardware
>

for such a design a developer should be fired ^^
Everything back to ring 0, however I guess that particular developer
who "designed" this does not
know about that security concept, otherwise he wouldn't propose to put
such things into kernelspace.

and from the kernel network stack you go via TCP and connect to
whoever you want (particular userspace
daemon with all the implementation).
Aside of the security issue which it introduces you won't even protect
what you try to protect because you
cannot control the connection.

It would be interesting if someone would implement it that way now, so
Mauro disqualified himself with this proposal.

Although please continue I'll keep watching, either result (supporting
or not supporting it) is fine with me.

Markus
> In other words, the "DVB net_tunnel" driver will take care of using the
> network stack, implement Kernel namespaces, etc, in order to allow virtualizing
> a remote hardware, without needing any userspace driver for doing that
> (well, except, of course, for the standard network userspace applications for
> DNS solving, configuring IP routes, etc).
>
> Cheers,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>