2011/6/21 Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>: > 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
