[RFC] vtunerc - virtual DVB device driver

[RFC] vtunerc - virtual DVB device driver

[HoP]

Hi,

get inspired by (unfortunately close-source) solution on stb
Dreambox 800 I have made my own implementation
of virtual DVB device, based on the same device API.

In conjunction with "Dreamtuner" userland project
[http://code.google.com/p/dreamtuner/] by Ronald Mieslinger
user can create virtual DVB device on client side and connect it
to the server. When connected, user is able to use any Linux DVB API
compatible application on client side (like VDR, MeTV, MythTV, etc)
without any need of code modification. As server can be used any
Linux DVB API compatible device.

Here is the small and ugly big picture :-)

            CLIENT                                    SERVER
--------------------------------      ---------------------------------
|  Favourite Linux DVB API |     |      Real DVB tuner HW       |
|  compatible application    |     |         (any S, C or T)          |
---------------------------------      ---------------------------------
                 |                                                  ^
    Linux DVB API layer                   Linux DVB API layer
                 |                                                  |
                v                                                  |
---------------------------------                          |
|           vtunerc.ko              |                          |
|     (virtual DVB device )    |                          |
---------------------------------                          |
                 |                                                  |
    /dev/vtunerX API layer                               |
                 |                                                  |
                v                                                  |
---------------------------------           ---------------------------------
|          vtunerc.x86            |            |          vtuners.arm
           |
|   (dreamtuner client app)  |           |  (dreamtuner server app)  |
--------------------------------            ---------------------------------
                 |                                                   ^
                 |                TCP/IP network             |
                 ------------------------------------------
                        dreamtuner network protocol


Note: current code was tested on kernels from 2.6.22 up to 2.6.38
and that is the reason of codeversion preprocessor ifdefs there.
I understand fully that such code must be removed for possible
code submission.

Signed-off-by: Honza Petrous <jpetrous@smartimp.cz>


diff -r a43a9e31be8b drivers/media/dvb/vtunerc/Kconfig
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/drivers/media/dvb/vtunerc/Kconfig	Sun Jun 19 01:55:52 2011 +0200
@@ -0,0 +1,13 @@
+config DVB_VTUNERC
+	tristate "Virtual DVB adapters support"
+	depends on DVB_CORE
+	---help---
+	  Support for virtual DVB adapter.
+
+	  Choose Y here if you want to access DVB device residing on other
+	  computers using vtuner protocol.  To compile this driver as a module,
+	  choose M here: the module will be called vtunerc.
+
+	  To connect remote DVB device, you also need to install the user space
+	  vtunerc command which can be found in the Dreamtuner package, available
+	  from http://code.google.com/p/dreamtuner/.
diff -r a43a9e31be8b drivers/media/dvb/vtunerc/Makefile
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/drivers/media/dvb/vtunerc/Makefile	Sun Jun 19 01:55:52 2011 +0200
@@ -0,0 +1,14 @@
+#
+# Makefile for the nGene device driver
+#
+
+vtunerc-objs = vtunerc_main.o vtunerc_ctrldev.o vtunerc_proxyfe.o
+
+obj-$(CONFIG_DVB_VTUNERC) += vtunerc.o
+
+EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
+EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
+EXTRA_CFLAGS += -Idrivers/media/common/tuners
+EXTRA_CFLAGS += -Iinclude/linux
+
+EXTRA_CFLAGS += -DHAVE_DVB_API_VERSION=5
diff -r a43a9e31be8b drivers/media/dvb/vtunerc/vtuner.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/drivers/media/dvb/vtunerc/vtuner.h	Sun Jun 19 01:55:52 2011 +0200
@@ -0,0 +1,163 @@
+/*
+ * vtunerc: /dev/vtunerc API
+ *
+ * Copyright (C) 2010-11 Honza Petrous <jpetrous@smartimp.cz>
+ * [based on dreamtuner userland code by Roland Mieslinger]
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _VTUNER_H_
+#define _VTUNER_H_
+
+#ifndef HAVE_DVB_API_VERSION
+#define HAVE_DVB_API_VERSION 5
+#endif
+
+#if HAVE_DVB_API_VERSION < 3
+  #include <ost/frontend.h>
+  #include <ost/dmx.h>
+  #include <ost/sec.h>
+#else
+  #include <linux/dvb/version.h>
+  #include <linux/dvb/frontend.h>
+  #include <linux/dvb/dmx.h>
+#endif
+
+#define VT_S   0x01
+#define VT_C   0x02
+#define VT_T   0x04
+#define VT_S2  0x08
+
+#define MSG_SET_FRONTEND		1
+#define MSG_GET_FRONTEND		2
+#define MSG_READ_STATUS			3
+#define MSG_READ_BER			4
+#define MSG_READ_SIGNAL_STRENGTH	5
+#define MSG_READ_SNR			6
+#define MSG_READ_UCBLOCKS		7
+#define MSG_SET_TONE			8
+#define MSG_SET_VOLTAGE			9
+#define MSG_ENABLE_HIGH_VOLTAGE		10
+#define MSG_SEND_DISEQC_MSG		11
+#define MSG_SEND_DISEQC_BURST		13
+#define MSG_PIDLIST			14
+#define MSG_TYPE_CHANGED		15
+#define MSG_SET_PROPERTY		16
+#define MSG_GET_PROPERTY		17
+
+#define MSG_NULL			1024
+#define MSG_DISCOVER			1025
+#define MSG_UPDATE       		1026
+
+struct diseqc_master_cmd {
+	__u8 msg[6];
+	__u8 msg_len;
+};
+
+#if DVB_API_VERSION < 5
+struct dtv_property {
+	__u32 cmd;
+	__u32 reserved[3];
+	union {
+		__u32 data;
+		struct {
+			__u8 data[32];
+			__u32 len;
+			__u32 reserved1[3];
+			void *reserved2;
+		} buffer;
+	} u;
+	int result;
+} __attribute__ ((packed));
+
+#define DTV_UNDEFINED		0
+#define DTV_TUNE		1
+#define DTV_CLEAR		2
+#define DTV_FREQUENCY		3
+#define DTV_MODULATION		4
+#define DTV_BANDWIDTH_HZ	5
+#define DTV_INVERSION		6
+#define DTV_DISEQC_MASTER	7
+#define DTV_SYMBOL_RATE		8
+#define DTV_INNER_FEC		9
+#define DTV_VOLTAGE		10
+#define DTV_TONE		11
+#define DTV_PILOT		12
+#define DTV_ROLLOFF		13
+#define DTV_DISEQC_SLAVE_REPLY	14
+#define DTV_FE_CAPABILITY_COUNT	15
+#define DTV_FE_CAPABILITY	16
+#define DTV_DELIVERY_SYSTEM	17
+
+#define DTV_IOCTL_MAX_MSGS	64
+
+#endif
+
+struct vtuner_message {
+	__s32 type;
+	union {
+		struct {
+			__u32	frequency;
+			__u8	inversion;
+			union {
+				struct {
+					__u32	symbol_rate;
+					__u32	fec_inner;
+				} qpsk;
+				struct {
+					__u32   symbol_rate;
+					__u32   fec_inner;
+					__u32	modulation;
+				} qam;
+				struct {
+					__u32	bandwidth;
+					__u32	code_rate_HP;
+					__u32	code_rate_LP;
+					__u32	constellation;
+					__u32	transmission_mode;
+					__u32	guard_interval;
+					__u32	hierarchy_information;
+				} ofdm;
+				struct {
+					__u32	modulation;
+				} vsb;
+			} u;
+		} fe_params;
+		struct dtv_property prop;
+		__u32 status;
+		__u32 ber;
+		__u16 ss;
+		__u16 snr;
+		__u32 ucb;
+		__u8 tone;
+		__u8 voltage;
+		struct diseqc_master_cmd diseqc_master_cmd;
+		__u8 burst;
+		__u16 pidlist[30];
+		__u8  pad[72];
+		__u32 type_changed;
+	} body;
+};
+
+#define VTUNER_MAJOR		226
+
+/*#define PVR_FLUSH_BUFFER	_IO(VTUNER_MAJOR, 0)*/
+#define VTUNER_GET_MESSAGE	_IOR(VTUNER_MAJOR, 1, struct vtuner_message *)
+#define VTUNER_SET_RESPONSE 	_IOW(VTUNER_MAJOR, 2, struct vtuner_message *)
+#define VTUNER_SET_NAME		_IOW(VTUNER_MAJOR, 3, char *)
+#define VTUNER_SET_TYPE		_IOW(VTUNER_MAJOR, 4, char *)
+#define VTUNER_SET_HAS_OUTPUTS	_IOW(VTUNER_MAJOR, 5, char *)
+#define VTUNER_SET_FE_INFO	_IOW(VTUNER_MAJOR, 6, struct dvb_frontend_info *)
+#define VTUNER_SET_NUM_MODES	_IOW(VTUNER_MAJOR, 7, int)
+#define VTUNER_SET_MODES	_IOW(VTUNER_MAJOR, 8, char *)
+
+#endif
+
diff -r a43a9e31be8b drivers/media/dvb/vtunerc/vtunerc_ctrldev.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/drivers/media/dvb/vtunerc/vtunerc_ctrldev.c	Sun Jun 19 01:55:52 2011 +0200
@@ -0,0 +1,427 @@
+/*
+ * vtunerc: /dev/vtunerc device
+ *
+ * Copyright (C) 2010-11 Honza Petrous <jpetrous@smartimp.cz>
+ * [Created 2010-03-23]
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/version.h>
+#include <linux/module.h>
+#include <linux/fs.h>
+#include <linux/delay.h>
+
+#include <linux/time.h>
+#include <linux/poll.h>
+
+#include "vtunerc_priv.h"
+
+#define VTUNERC_CTRLDEV_MAJOR	266
+#define VTUNERC_CTRLDEV_NAME	"vtunerc"
+
+#define VTUNER_MSG_LEN (sizeof(struct vtuner_message))
+
+static ssize_t vtunerc_ctrldev_write(struct file *filp, const char *buff,
+					size_t len, loff_t *off)
+{
+	struct vtunerc_ctx *vtunerc = filp->private_data;
+	struct dvb_demux *demux = &vtunerc->demux;
+	char *kernel_buf;
+	size_t origlen = len;
+
+	if (vtunerc->closing)
+		return -EINTR;
+
+	kernel_buf = kmalloc(len + vtunerc->trailsize, GFP_KERNEL);
+
+	if (kernel_buf == NULL)
+		return -ENOMEM;
+
+	if (down_interruptible(&vtunerc->tswrite_sem))
+		return -ERESTARTSYS;
+
+	if (vtunerc->trailsize)
+		memcpy(kernel_buf, vtunerc->trail, vtunerc->trailsize);
+
+	if (copy_from_user(kernel_buf + vtunerc->trailsize, buff, len)) {
+		printk(PRINTK_ERR "%s: ERR: in userdata passing\n", __func__);
+		up(&vtunerc->tswrite_sem);
+		return 0;
+	}
+
+	if (kernel_buf[0] != 0x47) { /* start of TS packet */
+		printk(PRINTK_ERR "%s: WARN: Data not start on packet boundary:
%02x %02x %02x %02x %02x ...\n",
+				__func__, kernel_buf[0], kernel_buf[1],
+				kernel_buf[2], kernel_buf[3], kernel_buf[4]);
+	}
+
+	len += vtunerc->trailsize;
+	vtunerc->trailsize = len % 188;
+	if ((vtunerc->trailsize)) {
+		/* saving last partial TS packet */
+		len -= vtunerc->trailsize;
+		memcpy(vtunerc->trail, kernel_buf + len, vtunerc->trailsize);
+	}
+
+	vtunerc->stat_wr_data += len;
+	dvb_dmx_swfilter_packets(demux, kernel_buf, len / 188);
+
+	up(&vtunerc->tswrite_sem);
+
+#ifdef CONFIG_PROC_FS
+	/* TODO:  analyze injected data for statistics */
+#endif
+
+	kfree(kernel_buf);
+
+	return origlen;
+}
+
+static ssize_t vtunerc_ctrldev_read(struct file *filp, char __user *buff,
+		size_t len, loff_t *off)
+{
+	struct vtunerc_ctx *vtunerc = filp->private_data;
+
+	vtunerc->stat_rd_data += len;
+
+	/* read op is not using in current vtuner protocol */
+	return 0 ;
+}
+
+static int vtunerc_ctrldev_open(struct inode *inode, struct file *filp)
+{
+	struct vtunerc_ctx *vtunerc;
+	int minor;
+
+	minor = MINOR(inode->i_rdev);
+	vtunerc = filp->private_data = vtunerc_get_ctx(minor);
+	if (vtunerc == NULL)
+		return -ENOMEM;
+
+	vtunerc->stat_ctrl_sess++;
+
+	/*FIXME: clear pidtab */
+
+	vtunerc->fd_opened++;
+	vtunerc->closing = 0;
+
+	return 0;
+}
+
+static int vtunerc_ctrldev_close(struct inode *inode, struct file *filp)
+{
+	struct vtunerc_ctx *vtunerc = filp->private_data;
+	int minor;
+	struct vtuner_message fakemsg;
+
+	vtunerc->fd_opened--;
+	vtunerc->closing = 1;
+
+	minor = MINOR(inode->i_rdev);
+
+	/* set FAKE response, to allow finish any waiters
+	   in vtunerc_ctrldev_xchange_message() */
+	vtunerc->ctrldev_response.type = 0;
+	wake_up_interruptible(&vtunerc->ctrldev_wait_response_wq);
+
+	/* clear pidtab */
+	if (down_interruptible(&vtunerc->xchange_sem))
+		return -ERESTARTSYS;
+	memset(&fakemsg, 0, sizeof(fakemsg));
+	vtunerc_ctrldev_xchange_message(vtunerc, &fakemsg, 0);
+	up(&vtunerc->xchange_sem);
+
+	return 0;
+}
+
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 16)
+static long vtunerc_ctrldev_ioctl(struct file *file, unsigned int cmd,
+					unsigned long arg)
+#else
+static int vtunerc_ctrldev_ioctl(struct inode *inode, struct file *file,
+					unsigned int cmd, unsigned long arg)
+#endif
+{
+	struct vtunerc_ctx *vtunerc = file->private_data;
+	int len, ret = 0;
+	int i;
+
+	if (vtunerc->closing)
+		return -EINTR;
+
+	if (down_interruptible(&vtunerc->ioctl_sem))
+		return -ERESTARTSYS;
+
+	switch (cmd) {
+	case VTUNER_SET_NAME:
+		len = strlen((char *)arg) + 1;
+		vtunerc->name = kmalloc(len, GFP_KERNEL);
+		if (vtunerc->name == NULL) {
+			printk(PRINTK_ERR "%s returns no mem\n", __func__);
+			ret = -ENOMEM;
+			break;
+		}
+		if (copy_from_user(vtunerc->name, (char *)arg, len)) {
+			ret = -EFAULT;
+			break;
+		}
+		break;
+
+	case VTUNER_SET_HAS_OUTPUTS:
+		/* TODO: faked for now */
+		break;
+
+	case VTUNER_SET_MODES:
+		for (i = 0; i < vtunerc->num_modes; i++)
+			vtunerc->ctypes[i] = &(((char *)(arg))[i*32]);
+		if (vtunerc->num_modes != 1) {
+			printk(PRINTK_ERR "%s currently supported only num_modes = 1!\n",
+					__func__);
+			break;
+		}
+		/* follow into old code for compatibility */
+
+	case VTUNER_SET_TYPE:
+		if (strcasecmp((char *)arg, "DVB-S") == 0) {
+			vtunerc->vtype = VT_S;
+			printk(PRINTK_NOTICE "%s setting DVB-S tuner vtype\n",
+					__func__);
+		} else
+		if (strcasecmp((char *)arg, "DVB-S2") == 0) {
+			vtunerc->vtype = VT_S2;
+			printk(PRINTK_NOTICE "%s setting DVB-S2 tuner vtype\n",
+					__func__);
+		} else
+		if (strcasecmp((char *)arg, "DVB-T") == 0) {
+			vtunerc->vtype = VT_T;
+			printk(PRINTK_NOTICE "%s setting DVB-T tuner vtype\n",
+					__func__);
+		} else
+		if (strcasecmp((char *)arg, "DVB-C") == 0) {
+			vtunerc->vtype = VT_C;
+			printk(PRINTK_NOTICE "%s setting DVB-C tuner vtype\n",
+					__func__);
+		} else {
+			printk(PRINTK_ERR "%s unregognized tuner vtype '%s'\n",
+					__func__, (char *)arg);
+			ret = -ENODEV;
+			break;
+		}
+
+		if ((vtunerc_frontend_init(vtunerc))) {
+			vtunerc->vtype = 0;
+			printk(PRINTK_ERR "%s failed to initialize tuner's internals\n",
+					__func__);
+			ret = -ENODEV;
+			break;
+		}
+
+		break;
+
+
+	case VTUNER_SET_FE_INFO:
+		len = sizeof(struct dvb_frontend_info);
+		vtunerc->feinfo = kmalloc(len, GFP_KERNEL);
+		if (vtunerc->feinfo == NULL) {
+			printk(PRINTK_ERR "%s return no mem<\n", __func__);
+			ret = -ENOMEM;
+			break;
+		}
+		if (copy_from_user(vtunerc->feinfo, (char *)arg, len)) {
+			ret = -EFAULT;
+			break;
+		}
+		break;
+
+	case VTUNER_GET_MESSAGE:
+		if (wait_event_interruptible(vtunerc->ctrldev_wait_request_wq,
+					vtunerc->ctrldev_request.type != -1)) {
+			ret = -ERESTARTSYS;
+			break;
+		}
+
+		BUG_ON(vtunerc->ctrldev_request.type == -1);
+
+		if (copy_to_user((char *)arg, &vtunerc->ctrldev_request,
+					VTUNER_MSG_LEN)) {
+			ret = -EFAULT;
+			break;
+		}
+
+		vtunerc->ctrldev_request.type = -1;
+
+		if (vtunerc->noresponse)
+			up(&vtunerc->xchange_sem);
+
+		break;
+
+	case VTUNER_SET_RESPONSE:
+		if (copy_from_user(&vtunerc->ctrldev_response, (char *)arg,
+					VTUNER_MSG_LEN)) {
+			ret = -EFAULT;
+		}
+		wake_up_interruptible(&vtunerc->ctrldev_wait_response_wq);
+
+		break;
+
+	case VTUNER_SET_NUM_MODES:
+		vtunerc->num_modes = (int) arg;
+		break;
+
+	default:
+		printk(PRINTK_WARN "vtunerc: WARN: unknown IOCTL 0x%x\n", cmd);
+
+		break;
+	}
+	up(&vtunerc->ioctl_sem);
+
+	return ret;
+}
+
+static unsigned int vtunerc_ctrldev_poll(struct file *filp, poll_table *wait)
+{
+	struct vtunerc_ctx *vtunerc = filp->private_data;
+	unsigned int mask = 0;
+
+	if (vtunerc->closing)
+		return -EINTR;
+
+	poll_wait(filp, &vtunerc->ctrldev_wait_request_wq, wait);
+
+	if (vtunerc->ctrldev_request.type >= -1 ||
+			vtunerc->ctrldev_response.type >= -1) {
+		mask = POLLPRI;
+	}
+
+  return mask;
+}
+
+/* ------------------------------------------------ */
+
+static const struct file_operations vtunerc_ctrldev_fops = {
+	.owner = THIS_MODULE,
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 16) /* see:
http://lwn.net/Articles/119652/ */
+	.unlocked_ioctl = vtunerc_ctrldev_ioctl,
+#else
+	.ioctl = vtunerc_ctrldev_ioctl,
+#endif
+	.write = vtunerc_ctrldev_write,
+	.read  = vtunerc_ctrldev_read,
+	.poll  = (void *) vtunerc_ctrldev_poll,
+	.open  = vtunerc_ctrldev_open,
+	.release  = vtunerc_ctrldev_close
+};
+
+static struct class *pclass;
+static struct cdev cdev;
+static dev_t chdev;
+extern int adapters;
+
+int vtunerc_register_ctrldev()
+{
+	int idx;
+
+	chdev = MKDEV(VTUNERC_CTRLDEV_MAJOR, 0);
+
+	if (register_chrdev_region(chdev, adapters, VTUNERC_CTRLDEV_NAME)) {
+		printk(PRINTK_ERR "vtunerc: ERR: unable to get major %d\n",
+				VTUNERC_CTRLDEV_MAJOR);
+		return -EINVAL;
+	}
+
+	cdev_init(&cdev, &vtunerc_ctrldev_fops);
+
+	cdev.owner = THIS_MODULE;
+	cdev.ops = &vtunerc_ctrldev_fops;
+
+	if (cdev_add(&cdev, chdev, adapters) < 0)
+		printk(PRINTK_WARN "vtunerc: WARN: unable to create dev\n");
+
+	pclass = class_create(THIS_MODULE, "vtuner");
+	if (IS_ERR(pclass)) {
+		printk(PRINTK_ERR "vtunerc: ERR: unable to register major %d\n",
+				VTUNERC_CTRLDEV_MAJOR);
+		return PTR_ERR(pclass);
+	}
+
+	for (idx = 0; idx < adapters; idx++) {
+		struct device *clsdev;
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 27)
+		clsdev = device_create(pclass, NULL,
+				MKDEV(VTUNERC_CTRLDEV_MAJOR, idx),
+				"vtunerc%d", idx);
+#else
+		clsdev = device_create(pclass, NULL,
+				MKDEV(VTUNERC_CTRLDEV_MAJOR, idx),
+				/*ctx*/ NULL, "vtunerc%d", idx);
+#endif
+		printk(PRINTK_NOTICE "vtunerc: registered /dev/vtunerc%d\n",
+				idx);
+	}
+
+	return 0;
+}
+
+void vtunerc_unregister_ctrldev()
+{
+	int idx;
+
+	printk(PRINTK_NOTICE "vtunerc: unregistering\n");
+
+	unregister_chrdev_region(chdev, adapters);
+
+	for (idx = 0; idx < adapters; idx++)
+		device_destroy(pclass, MKDEV(VTUNERC_CTRLDEV_MAJOR, idx));
+
+	cdev_del(&cdev);
+
+	class_destroy(pclass);
+}
+
+
+int vtunerc_ctrldev_xchange_message(struct vtunerc_ctx *vtunerc,
+		struct vtuner_message *msg, int wait4response)
+{
+	if (down_interruptible(&vtunerc->xchange_sem))
+		return -ERESTARTSYS;
+
+	if (vtunerc->fd_opened < 1) {
+		up(&vtunerc->xchange_sem);
+		return 0;
+	}
+
+	BUG_ON(vtunerc->ctrldev_request.type != -1);
+
+	memcpy(&vtunerc->ctrldev_request, msg, sizeof(struct vtuner_message));
+	vtunerc->ctrldev_response.type = -1;
+	vtunerc->noresponse = !wait4response;
+	wake_up_interruptible(&vtunerc->ctrldev_wait_request_wq);
+
+	if (!wait4response)
+		return 0;
+
+	if (wait_event_interruptible(vtunerc->ctrldev_wait_response_wq,
+				vtunerc->ctrldev_response.type != -1)) {
+		up(&vtunerc->xchange_sem);
+		return -ERESTARTSYS;
+	}
+
+	BUG_ON(vtunerc->ctrldev_response.type == -1);
+
+	memcpy(msg, &vtunerc->ctrldev_response, sizeof(struct vtuner_message));
+	vtunerc->ctrldev_response.type = -1;
+
+	up(&vtunerc->xchange_sem);
+
+	return 0;
+}
diff -r a43a9e31be8b drivers/media/dvb/vtunerc/vtunerc_main.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/drivers/media/dvb/vtunerc/vtunerc_main.c	Sun Jun 19 01:55:52 2011 +0200
@@ -0,0 +1,396 @@
+/*
+ * vtunerc: Virtual adapter driver
+ *
+ * Copyright (C) 2010-11 Honza Petrous <jpetrous@smartimp.cz>
+ * [Created 2010-03-23]
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>	/* Specifically, a module */
+#include <linux/kernel.h>	/* We're doing kernel work */
+#include <linux/proc_fs.h>
+#include <linux/init.h>
+#include <linux/i2c.h>
+#include <asm/uaccess.h>
+#include <linux/delay.h>
+
+#include "demux.h"
+#include "dmxdev.h"
+#include "dvb_demux.h"
+#include "dvb_frontend.h"
+#include "dvb_net.h"
+#include "dvbdev.h"
+
+#include "vtuner.h"
+
+#include "vtunerc_priv.h"
+
+#define VTUNERC_MODULE_VERSION "0.12"
+
+#define MSGHEADER "[vtunerc]: "
+
+DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+
+#define DRIVER_NAME		"vTuner proxy"
+
+#define VTUNERC_PROC_FILENAME	"vtunerc%i"
+
+#define VTUNERC_MAX_ADAPTERS	4
+
+static struct vtunerc_ctx *vtunerc_tbl[VTUNERC_MAX_ADAPTERS] = { NULL };
+
+int adapters = 1;
+
+static int pidtab_find_index(unsigned short *pidtab, int pid)
+{
+	int i = 0;
+
+	while (i < MAX_PIDTAB_LEN) {
+		if (pidtab[i] == pid)
+			return i;
+		i++;
+	}
+
+	return -1;
+}
+
+static int pidtab_add_pid(unsigned short *pidtab, int pid)
+{
+	int i;
+
+	/* TODO: speed-up hint: add pid sorted */
+
+	for (i = 0; i < MAX_PIDTAB_LEN; i++)
+		if (pidtab[i] == PID_UNKNOWN) {
+			pidtab[i] = pid;
+			return 0;
+		}
+
+	return -1;
+}
+
+static int pidtab_del_pid(unsigned short *pidtab, int pid)
+{
+	int i;
+
+	/* TODO: speed-up hint: delete sorted */
+
+	for (i = 0; i < MAX_PIDTAB_LEN; i++)
+		if (pidtab[i] == pid) {
+			pidtab[i] = PID_UNKNOWN;
+			/* TODO: move rest */
+			return 0;
+		}
+
+	return -1;
+}
+
+static void pidtab_copy_to_msg(struct vtunerc_ctx *vtunerc,
+				struct vtuner_message *msg)
+{
+	int i;
+
+	for (i = 0; i < (MAX_PIDTAB_LEN - 1); i++)
+		msg->body.pidlist[i] = vtunerc->pidtab[i]; /*TODO: optimize it*/
+	msg->body.pidlist[MAX_PIDTAB_LEN - 1] = 0;
+}
+
+static int vtunerc_start_feed(struct dvb_demux_feed *feed)
+{
+	struct dvb_demux *demux = feed->demux;
+	struct vtunerc_ctx *vtunerc = demux->priv;
+	struct vtuner_message msg;
+
+	switch (feed->type) {
+	case DMX_TYPE_TS:
+		break;
+	case DMX_TYPE_SEC:
+		break;
+	case DMX_TYPE_PES:
+		printk(MSGHEADER " feed type PES is not supported\n");
+		return -EINVAL;
+	default:
+		printk(MSGHEADER " feed type %d is not supported\n",
+				feed->type);
+		return -EINVAL;
+	}
+
+	/* organize PID list table */
+
+	if (pidtab_find_index(vtunerc->pidtab, feed->pid) < 0) {
+		pidtab_add_pid(vtunerc->pidtab, feed->pid);
+
+		pidtab_copy_to_msg(vtunerc, &msg);
+
+		msg.type = MSG_PIDLIST;
+		vtunerc_ctrldev_xchange_message(vtunerc, &msg, 0);
+	}
+
+	return 0;
+}
+
+static int vtunerc_stop_feed(struct dvb_demux_feed *feed)
+{
+	struct dvb_demux *demux = feed->demux;
+	struct vtunerc_ctx *vtunerc = demux->priv;
+	struct vtuner_message msg;
+
+	/* organize PID list table */
+
+	if (pidtab_find_index(vtunerc->pidtab, feed->pid) > -1) {
+		pidtab_del_pid(vtunerc->pidtab, feed->pid);
+
+		pidtab_copy_to_msg(vtunerc, &msg);
+
+		msg.type = MSG_PIDLIST;
+		vtunerc_ctrldev_xchange_message(vtunerc, &msg, 0);
+	}
+
+	return 0;
+}
+
+/* ----------------------------------------------------------- */
+
+
+#ifdef CONFIG_PROC_FS
+#define MAXBUF 512
+/**
+ * @brief  procfs file handler
+ * @param  buffer:
+ * @param  start:
+ * @param  offset:
+ * @param  size:
+ * @param  eof:
+ * @param  data:
+ * @return =0: success <br/>
+ *         <0: if any error occur
+ */
+int vtunerc_read_proc(char *buffer, char **start, off_t offset, int size,
+			int *eof, void *data)
+{
+	char outbuf[MAXBUF] = "[ vtunerc driver, version "
+				VTUNERC_MODULE_VERSION " ]\n";
+	int blen, i, pcnt;
+	struct vtunerc_ctx *vtunerc = (struct vtunerc_ctx *)data;
+
+	blen = strlen(outbuf);
+	sprintf(outbuf+blen, "  sessions: %u\n", vtunerc->stat_ctrl_sess);
+	blen = strlen(outbuf);
+	sprintf(outbuf+blen, "  read    : %u\n", vtunerc->stat_rd_data);
+	blen = strlen(outbuf);
+	sprintf(outbuf+blen, "  write   : %u\n", vtunerc->stat_wr_data);
+	blen = strlen(outbuf);
+	sprintf(outbuf+blen, "  PID tab :");
+	pcnt = 0;
+	for (i = 0; i < MAX_PIDTAB_LEN; i++) {
+		blen = strlen(outbuf);
+		if (vtunerc->pidtab[i] != PID_UNKNOWN) {
+			sprintf(outbuf+blen, " %x", vtunerc->pidtab[i]);
+			pcnt++;
+		}
+	}
+	blen = strlen(outbuf);
+	sprintf(outbuf+blen, " (len=%d)\n", pcnt);
+
+	blen = strlen(outbuf);
+
+	if (size < blen)
+		return -EINVAL;
+
+	if (offset != 0)
+		return 0;
+
+	strcpy(buffer, outbuf);
+
+	/* signal EOF */
+	*eof = 1;
+
+	return blen;
+
+}
+#endif
+
+static char *my_strdup(const char *s)
+{
+	char *rv = kmalloc(strlen(s)+1, GFP_KERNEL);
+	if (rv)
+		strcpy(rv, s);
+	return rv;
+}
+
+struct vtunerc_ctx *vtunerc_get_ctx(int minor)
+{
+	if (minor >= VTUNERC_MAX_ADAPTERS)
+		return NULL;
+
+	return vtunerc_tbl[minor];
+}
+
+static int __init vtunerc_init(void)
+{
+	struct vtunerc_ctx *vtunerc;
+	struct dvb_demux *dvbdemux;
+	struct dmx_demux *dmx;
+	int ret = -EINVAL, i, idx;
+
+	printk(KERN_INFO "vTunerc DVB multi adapter driver, version "
+			VTUNERC_MODULE_VERSION
+			", (c) 2010-11 Honza Petrous, SmartImp.cz\n");
+
+	request_module("dvb-core"); /* FIXME: dunno which way it should work :-/ */
+
+	for (idx = 0; idx < adapters; idx++) {
+		vtunerc = kzalloc(sizeof(struct vtunerc_ctx), GFP_KERNEL);
+		if (!vtunerc)
+			return -ENOMEM;
+
+		vtunerc_tbl[idx] = vtunerc;
+
+		vtunerc->idx = idx;
+		vtunerc->ctrldev_request.type = -1;
+		vtunerc->ctrldev_response.type = -1;
+		init_waitqueue_head(&vtunerc->ctrldev_wait_request_wq);
+		init_waitqueue_head(&vtunerc->ctrldev_wait_response_wq);
+
+		/* dvb */
+
+		/* create new adapter */
+		ret = dvb_register_adapter(&vtunerc->dvb_adapter, DRIVER_NAME,
+					   THIS_MODULE, NULL, adapter_nr);
+		if (ret < 0)
+			goto err_kfree;
+
+		vtunerc->dvb_adapter.priv = vtunerc;
+
+		memset(&vtunerc->demux, 0, sizeof(vtunerc->demux));
+		dvbdemux = &vtunerc->demux;
+		dvbdemux->priv = vtunerc;
+		dvbdemux->filternum = MAX_PIDTAB_LEN;
+		dvbdemux->feednum = MAX_PIDTAB_LEN;
+		dvbdemux->start_feed = vtunerc_start_feed;
+		dvbdemux->stop_feed = vtunerc_stop_feed;
+		dvbdemux->dmx.capabilities = 0;
+		ret = dvb_dmx_init(dvbdemux);
+		if (ret < 0)
+			goto err_dvb_unregister_adapter;
+
+		dmx = &dvbdemux->dmx;
+
+		vtunerc->hw_frontend.source = DMX_FRONTEND_0;
+		vtunerc->mem_frontend.source = DMX_MEMORY_FE;
+		vtunerc->dmxdev.filternum = MAX_PIDTAB_LEN;
+		vtunerc->dmxdev.demux = dmx;
+
+		ret = dvb_dmxdev_init(&vtunerc->dmxdev, &vtunerc->dvb_adapter);
+		if (ret < 0)
+			goto err_dvb_dmx_release;
+
+		ret = dmx->add_frontend(dmx, &vtunerc->hw_frontend);
+		if (ret < 0)
+			goto err_dvb_dmxdev_release;
+
+		ret = dmx->add_frontend(dmx, &vtunerc->mem_frontend);
+		if (ret < 0)
+			goto err_remove_hw_frontend;
+
+		ret = dmx->connect_frontend(dmx, &vtunerc->hw_frontend);
+		if (ret < 0)
+			goto err_remove_mem_frontend;
+
+		sema_init(&vtunerc->xchange_sem, 1);
+		sema_init(&vtunerc->ioctl_sem, 1);
+		sema_init(&vtunerc->tswrite_sem, 1);
+
+		/* init pid table */
+		for (i = 0; i < MAX_PIDTAB_LEN; i++)
+			vtunerc->pidtab[i] = PID_UNKNOWN;
+
+#ifdef CONFIG_PROC_FS
+		{
+			char procfilename[64];
+
+			sprintf(procfilename, VTUNERC_PROC_FILENAME,
+					vtunerc->idx);
+			vtunerc->procname = my_strdup(procfilename);
+			if (create_proc_read_entry(vtunerc->procname, 0, NULL,
+							vtunerc_read_proc,
+							vtunerc) == 0)
+				printk(MSGHEADER
+					"Unable to register '%s' proc file\n",
+					vtunerc->procname);
+		}
+#endif
+	}
+
+	vtunerc_register_ctrldev();
+
+out:
+	return ret;
+
+	dmx->disconnect_frontend(dmx);
+err_remove_mem_frontend:
+	dmx->remove_frontend(dmx, &vtunerc->mem_frontend);
+err_remove_hw_frontend:
+	dmx->remove_frontend(dmx, &vtunerc->hw_frontend);
+err_dvb_dmxdev_release:
+	dvb_dmxdev_release(&vtunerc->dmxdev);
+err_dvb_dmx_release:
+	dvb_dmx_release(dvbdemux);
+err_dvb_unregister_adapter:
+	dvb_unregister_adapter(&vtunerc->dvb_adapter);
+err_kfree:
+	kfree(vtunerc);
+	goto out;
+}
+
+static void __exit vtunerc_exit(void)
+{
+	struct dvb_demux *dvbdemux;
+	struct dmx_demux *dmx;
+	int idx;
+
+	vtunerc_unregister_ctrldev();
+
+	for (idx = 0; idx < adapters; idx++) {
+		struct vtunerc_ctx *vtunerc = vtunerc_tbl[idx];
+#ifdef CONFIG_PROC_FS
+		remove_proc_entry(vtunerc->procname, NULL);
+		kfree(vtunerc->procname);
+#endif
+
+		vtunerc_frontend_clear(vtunerc);
+
+		dvbdemux = &vtunerc->demux;
+		dmx = &dvbdemux->dmx;
+
+		dmx->disconnect_frontend(dmx);
+		dmx->remove_frontend(dmx, &vtunerc->mem_frontend);
+		dmx->remove_frontend(dmx, &vtunerc->hw_frontend);
+		dvb_dmxdev_release(&vtunerc->dmxdev);
+		dvb_dmx_release(dvbdemux);
+		dvb_unregister_adapter(&vtunerc->dvb_adapter);
+		kfree(vtunerc);
+	}
+
+	printk(MSGHEADER " unloaded successfully\n");
+}
+
+module_init(vtunerc_init);
+module_exit(vtunerc_exit);
+
+MODULE_AUTHOR("Honza Petrous");
+MODULE_DESCRIPTION("virtual DVB device");
+MODULE_LICENSE("GPL");
+MODULE_VERSION(VTUNERC_MODULE_VERSION);
+
+module_param(adapters, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP);
+MODULE_PARM_DESC(adapters, "Number of virtual adapters (default is 1)");
+
diff -r a43a9e31be8b drivers/media/dvb/vtunerc/vtunerc_priv.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/drivers/media/dvb/vtunerc/vtunerc_priv.h	Sun Jun 19 01:55:52 2011 +0200
@@ -0,0 +1,100 @@
+/*
+ * vtunerc: Internal defines
+ *
+ * Copyright (C) 2010-11 Honza Petrous <jpetrous@smartimp.cz>
+ * [Created 2010-03-23]
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _VTUNERC_PRIV_H
+#define _VTUNERC_PRIV_H
+
+#include <linux/module.h>	/* Specifically, a module */
+#include <linux/kernel.h>	/* We're doing kernel work */
+#include <linux/cdev.h>
+
+#include "demux.h"
+#include "dmxdev.h"
+#include "dvb_demux.h"
+#include "dvb_frontend.h"
+#include "dvb_net.h"
+#include "dvbdev.h"
+
+#include "vtuner.h"
+
+#define MAX_PIDTAB_LEN 30
+
+#define PID_UNKNOWN 0x0FFFF
+
+#define MAX_NUM_VTUNER_MODES 3
+
+struct vtunerc_ctx {
+
+	/* DVB api */
+	struct dmx_frontend hw_frontend;
+	struct dmx_frontend mem_frontend;
+	struct dmxdev dmxdev;
+	struct dmxdev dmxdev1;
+	struct dmxdev dmxdev2;
+	struct dvb_adapter dvb_adapter;
+	struct dvb_demux demux;
+	struct dvb_frontend *fe;
+	struct dvb_net dvbnet;
+	struct dvb_device *ca;
+
+	/* internals */
+	int idx;
+	char *name;
+	__u8 vtype;
+	struct dvb_frontend_info *feinfo;
+
+	unsigned short pidtab[MAX_PIDTAB_LEN];
+
+	struct semaphore xchange_sem;
+	struct semaphore ioctl_sem;
+	struct semaphore tswrite_sem;
+	int fd_opened;
+	int closing;
+
+	char *procname;
+
+	/* ctrldev */
+	char trail[188];
+	unsigned int trailsize;
+	int noresponse;
+	int num_modes;
+	char *ctypes[MAX_NUM_VTUNER_MODES];
+	struct vtuner_message ctrldev_request;
+	struct vtuner_message ctrldev_response;
+	wait_queue_head_t ctrldev_wait_request_wq;
+	wait_queue_head_t ctrldev_wait_response_wq;
+
+	/* proc statistics */
+	unsigned int stat_wr_data;
+	unsigned int stat_rd_data;
+	unsigned int stat_ctrl_sess;
+	unsigned short pidstat[MAX_PIDTAB_LEN];
+};
+
+int vtunerc_register_ctrldev(void);
+void vtunerc_unregister_ctrldev(void);
+struct vtunerc_ctx *vtunerc_get_ctx(int minor);
+int /*__devinit*/ vtunerc_frontend_init(struct vtunerc_ctx *ctx);
+int /*__devinit*/ vtunerc_frontend_clear(struct vtunerc_ctx *ctx);
+int vtunerc_ctrldev_xchange_message(struct vtunerc_ctx *ctx,
+					struct vtuner_message *msg,
+					int wait4response);
+
+#define PRINTK_ERR ""
+#define PRINTK_WARN ""
+#define PRINTK_NOTICE ""
+
+#endif
diff -r a43a9e31be8b drivers/media/dvb/vtunerc/vtunerc_proxyfe.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/drivers/media/dvb/vtunerc/vtunerc_proxyfe.c	Sun Jun 19 01:55:52 2011 +0200
@@ -0,0 +1,573 @@
+/*
+ * vtunerc: Driver for Proxy Frontend
+ *
+ * Copyright (C) 2010-11 Honza Petrous <jpetrous@smartimp.cz>
+ * [Inspired on proxy frontend by Emard <emard@softhome.net>]
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/string.h>
+#include <linux/slab.h>
+
+#include "dvb_frontend.h"
+
+#include "vtunerc_priv.h"
+
+struct dvb_proxyfe_state {
+	struct dvb_frontend frontend;
+	struct vtunerc_ctx *vtunerc;
+};
+
+
+static int dvb_proxyfe_read_status(struct dvb_frontend *fe,
fe_status_t *status)
+{
+	struct dvb_proxyfe_state *state = fe->demodulator_priv;
+	struct vtunerc_ctx *vtunerc = state->vtunerc;
+	struct vtuner_message msg;
+
+	msg.type = MSG_READ_STATUS;
+	vtunerc_ctrldev_xchange_message(vtunerc, &msg, 1);
+
+	*status = msg.body.status;
+
+	return 0;
+}
+
+static int dvb_proxyfe_read_ber(struct dvb_frontend *fe, u32 *ber)
+{
+	struct dvb_proxyfe_state *state = fe->demodulator_priv;
+	struct vtunerc_ctx *vtunerc = state->vtunerc;
+	struct vtuner_message msg;
+
+	msg.type = MSG_READ_BER;
+	vtunerc_ctrldev_xchange_message(vtunerc, &msg, 1);
+
+	*ber = msg.body.ber;
+
+	return 0;
+}
+
+static int dvb_proxyfe_read_signal_strength(struct dvb_frontend *fe,
+						u16 *strength)
+{
+	struct dvb_proxyfe_state *state = fe->demodulator_priv;
+	struct vtunerc_ctx *vtunerc = state->vtunerc;
+	struct vtuner_message msg;
+
+	msg.type = MSG_READ_SIGNAL_STRENGTH;
+	vtunerc_ctrldev_xchange_message(vtunerc, &msg, 1);
+
+	*strength = msg.body.ss;
+
+	return 0;
+}
+
+static int dvb_proxyfe_read_snr(struct dvb_frontend *fe, u16 *snr)
+{
+	struct dvb_proxyfe_state *state = fe->demodulator_priv;
+	struct vtunerc_ctx *vtunerc = state->vtunerc;
+	struct vtuner_message msg;
+
+	msg.type = MSG_READ_SNR;
+	vtunerc_ctrldev_xchange_message(vtunerc, &msg, 1);
+
+	*snr = msg.body.snr;
+
+	return 0;
+}
+
+static int dvb_proxyfe_read_ucblocks(struct dvb_frontend *fe, u32 *ucblocks)
+{
+	struct dvb_proxyfe_state *state = fe->demodulator_priv;
+	struct vtunerc_ctx *vtunerc = state->vtunerc;
+	struct vtuner_message msg;
+
+	msg.type = MSG_READ_UCBLOCKS;
+	vtunerc_ctrldev_xchange_message(vtunerc, &msg, 1);
+
+	*ucblocks = msg.body.ucb;
+
+	return 0;
+}
+
+static int dvb_proxyfe_get_frontend(struct dvb_frontend *fe,
+					struct dvb_frontend_parameters *p)
+{
+	struct dvb_proxyfe_state *state = fe->demodulator_priv;
+	struct vtunerc_ctx *vtunerc = state->vtunerc;
+	struct vtuner_message msg;
+
+	msg.type = MSG_GET_FRONTEND;
+	vtunerc_ctrldev_xchange_message(vtunerc, &msg, 1);
+
+	switch (vtunerc->vtype) {
+	case VT_S:
+	case VT_S2:
+		/*FIXME*/
+		{
+			struct dvb_qpsk_parameters *op = &p->u.qpsk;
+
+			op->symbol_rate = msg.body.fe_params.u.qpsk.symbol_rate;
+			op->fec_inner = msg.body.fe_params.u.qpsk.fec_inner;
+		}
+		break;
+	case VT_T:
+		{
+			struct dvb_ofdm_parameters *op = &p->u.ofdm;
+
+			op->bandwidth = msg.body.fe_params.u.ofdm.bandwidth;
+			op->code_rate_HP = msg.body.fe_params.u.ofdm.code_rate_HP;
+			op->code_rate_LP = msg.body.fe_params.u.ofdm.code_rate_LP;
+			op->constellation = msg.body.fe_params.u.ofdm.constellation;
+			op->transmission_mode = msg.body.fe_params.u.ofdm.transmission_mode;
+			op->guard_interval = msg.body.fe_params.u.ofdm.guard_interval;
+			op->hierarchy_information = msg.body.fe_params.u.ofdm.hierarchy_information;
+		}
+		break;
+	case VT_C:
+		/*FIXME*/
+		break;
+	default:
+		printk(PRINTK_ERR "%s unregognized tuner vtype = %d\n", __func__,
vtunerc->vtype);
+		return -EINVAL;
+	}
+	p->frequency = msg.body.fe_params.frequency;
+	p->inversion = msg.body.fe_params.inversion;
+	return 0;
+}
+
+static int dvb_proxyfe_set_frontend(struct dvb_frontend *fe,
+					struct dvb_frontend_parameters *p)
+{
+	struct dvb_proxyfe_state *state = fe->demodulator_priv;
+	struct vtunerc_ctx *vtunerc = state->vtunerc;
+	struct vtuner_message msg;
+
+	memset(&msg, 0, sizeof(msg));
+	msg.body.fe_params.frequency = p->frequency;
+	msg.body.fe_params.inversion = p->inversion;
+
+	switch (vtunerc->vtype) {
+	case VT_S:
+	case VT_S2:
+		{
+			struct dvb_qpsk_parameters *op = &p->u.qpsk;
+#if HAVE_DVB_API_VERSION >= 5
+			struct dtv_frontend_properties *props = &fe->dtv_property_cache;
+#endif
+
+			msg.body.fe_params.u.qpsk.symbol_rate = op->symbol_rate;
+			msg.body.fe_params.u.qpsk.fec_inner = op->fec_inner;
+
+#if HAVE_DVB_API_VERSION >= 5
+			if (vtunerc->vtype == VT_S2 && props->delivery_system == SYS_DVBS2) {
+				/* DELIVERY SYSTEM: S2 delsys in use */
+				msg.body.fe_params.u.qpsk.fec_inner = 9;
+
+				/* MODULATION */
+				if (props->modulation == PSK_8)
+					/* signal PSK_8 modulation used */
+					msg.body.fe_params.u.qpsk.fec_inner += 9;
+
+				/* FEC */
+				switch (props->fec_inner) {
+				case FEC_1_2:
+					msg.body.fe_params.u.qpsk.fec_inner += 1;
+					break;
+				case FEC_2_3:
+					msg.body.fe_params.u.qpsk.fec_inner += 2;
+					break;
+				case FEC_3_4:
+					msg.body.fe_params.u.qpsk.fec_inner += 3;
+					break;
+				case FEC_4_5:
+					msg.body.fe_params.u.qpsk.fec_inner += 8;
+					break;
+				case FEC_5_6:
+					msg.body.fe_params.u.qpsk.fec_inner += 4;
+					break;
+				/*case FEC_6_7: // undefined
+					msg.body.fe_params.u.qpsk.fec_inner += 2;
+					break;*/
+				case FEC_7_8:
+					msg.body.fe_params.u.qpsk.fec_inner += 5;
+					break;
+				case FEC_8_9:
+					msg.body.fe_params.u.qpsk.fec_inner += 6;
+					break;
+				/*case FEC_AUTO: // undefined
+					msg.body.fe_params.u.qpsk.fec_inner += 2;
+					break;*/
+				case FEC_3_5:
+					msg.body.fe_params.u.qpsk.fec_inner += 7;
+					break;
+				case FEC_9_10:
+					msg.body.fe_params.u.qpsk.fec_inner += 9;
+					break;
+				default:
+					; /*FIXME: what now? */
+					break;
+				}
+
+				/* ROLLOFF */
+				switch (props->rolloff) {
+				case ROLLOFF_20:
+					msg.body.fe_params.inversion |= 0x08;
+					break;
+				case ROLLOFF_25:
+					msg.body.fe_params.inversion |= 0x04;
+					break;
+				case ROLLOFF_35:
+				default:
+					break;
+				}
+
+				/* PILOT */
+				switch (props->pilot) {
+				case PILOT_ON:
+					msg.body.fe_params.inversion |= 0x10;
+					break;
+				case PILOT_AUTO:
+					msg.body.fe_params.inversion |= 0x20;
+					break;
+				case PILOT_OFF:
+				default:
+					break;
+				}
+			}
+#endif /* HAVE_DVB_API_VERSION >= 5 */
+		}
+		break;
+	case VT_T:
+		{
+			struct dvb_ofdm_parameters *op = &p->u.ofdm;
+
+			msg.body.fe_params.u.ofdm.bandwidth = op->bandwidth;
+			msg.body.fe_params.u.ofdm.code_rate_HP = op->code_rate_HP;
+			msg.body.fe_params.u.ofdm.code_rate_LP = op->code_rate_LP;
+			msg.body.fe_params.u.ofdm.constellation = op->constellation;
+			msg.body.fe_params.u.ofdm.transmission_mode = op->transmission_mode;
+			msg.body.fe_params.u.ofdm.guard_interval = op->guard_interval;
+			msg.body.fe_params.u.ofdm.hierarchy_information = op->hierarchy_information;
+		}
+		break;
+	case VT_C:
+		/*TODO*/
+	default:
+		printk(PRINTK_ERR "%s: unregognized tuner vtype = %d\n", __func__,
+				vtunerc->vtype);
+		return -EINVAL;
+	}
+
+	msg.type = MSG_SET_FRONTEND;
+	vtunerc_ctrldev_xchange_message(vtunerc, &msg, 1);
+
+	return 0;
+}
+
+#if HAVE_DVB_API_VERSION >= 5
+static int dvb_proxyfe_get_property(struct dvb_frontend *fe, struct
dtv_property* tvp)
+{
+	return 0;
+}
+
+static enum dvbfe_algo dvb_proxyfe_get_frontend_algo(struct dvb_frontend *fe)
+{
+	return DVBFE_ALGO_SW;
+}
+
+#endif /* HAVE_DVB_API_VERSION >= 5 */
+
+static int dvb_proxyfe_sleep(struct dvb_frontend *fe)
+{
+	return 0;
+}
+
+static int dvb_proxyfe_init(struct dvb_frontend *fe)
+{
+	return 0;
+}
+
+static int dvb_proxyfe_set_tone(struct dvb_frontend *fe,
fe_sec_tone_mode_t tone)
+{
+	struct dvb_proxyfe_state *state = fe->demodulator_priv;
+	struct vtunerc_ctx *vtunerc = state->vtunerc;
+	struct vtuner_message msg;
+
+	msg.body.tone = tone;
+	msg.type = MSG_SET_TONE;
+	vtunerc_ctrldev_xchange_message(vtunerc, &msg, 1);
+
+	return 0;
+}
+
+static int dvb_proxyfe_set_voltage(struct dvb_frontend *fe,
fe_sec_voltage_t voltage)
+{
+	struct dvb_proxyfe_state *state = fe->demodulator_priv;
+	struct vtunerc_ctx *vtunerc = state->vtunerc;
+	struct vtuner_message msg;
+
+	msg.body.voltage = voltage;
+	msg.type = MSG_SET_VOLTAGE;
+	vtunerc_ctrldev_xchange_message(vtunerc, &msg, 1);
+
+	return 0;
+}
+
+static int dvb_proxyfe_send_diseqc_msg(struct dvb_frontend *fe,
struct dvb_diseqc_master_cmd *cmd)
+{
+	struct dvb_proxyfe_state *state = fe->demodulator_priv;
+	struct vtunerc_ctx *vtunerc = state->vtunerc;
+	struct vtuner_message msg;
+
+	memcpy(&msg.body.diseqc_master_cmd, cmd, sizeof(struct
dvb_diseqc_master_cmd));
+	msg.type = MSG_SEND_DISEQC_MSG;
+	vtunerc_ctrldev_xchange_message(vtunerc, &msg, 1);
+
+	return 0;
+}
+
+static int dvb_proxyfe_send_diseqc_burst(struct dvb_frontend *fe,
fe_sec_mini_cmd_t burst)
+{
+	struct dvb_proxyfe_state *state = fe->demodulator_priv;
+	struct vtunerc_ctx *vtunerc = state->vtunerc;
+	struct vtuner_message msg;
+
+	msg.body.burst = burst;
+	msg.type = MSG_SEND_DISEQC_BURST;
+	vtunerc_ctrldev_xchange_message(vtunerc, &msg, 1);
+
+	return 0;
+}
+
+static void dvb_proxyfe_release(struct dvb_frontend *fe)
+{
+	struct dvb_proxyfe_state *state = fe->demodulator_priv;
+
+	kfree(state);
+}
+
+static struct dvb_frontend_ops dvb_proxyfe_ofdm_ops;
+
+static struct dvb_frontend *dvb_proxyfe_ofdm_attach(struct
vtunerc_ctx *vtunerc)
+{
+	struct dvb_proxyfe_state *state = NULL;
+
+	/* allocate memory for the internal state */
+	state = kmalloc(sizeof(struct dvb_proxyfe_state), GFP_KERNEL);
+	if (state == NULL)
+		goto error;
+
+	/* create dvb_frontend */
+	memcpy(&state->frontend.ops, &dvb_proxyfe_ofdm_ops, sizeof(struct
dvb_frontend_ops));
+	state->frontend.demodulator_priv = state;
+	state->vtunerc = vtunerc;
+	return &state->frontend;
+
+error:
+	kfree(state);
+	return NULL;
+}
+
+static struct dvb_frontend_ops dvb_proxyfe_qpsk_ops;
+
+static struct dvb_frontend *dvb_proxyfe_qpsk_attach(struct
vtunerc_ctx *vtunerc, int can_2g_modulation)
+{
+	struct dvb_proxyfe_state *state = NULL;
+
+	/* allocate memory for the internal state */
+	state = kmalloc(sizeof(struct dvb_proxyfe_state), GFP_KERNEL);
+	if (state == NULL)
+		goto error;
+
+	/* create dvb_frontend */
+	memcpy(&state->frontend.ops, &dvb_proxyfe_qpsk_ops, sizeof(struct
dvb_frontend_ops));
+#if HAVE_DVB_API_VERSION >= 5
+	if (can_2g_modulation) {
+		state->frontend.ops.info.caps |= FE_CAN_2G_MODULATION;
+		strcpy(state->frontend.ops.info.name, "vTuner proxyFE DVB-S2");
+	}
+#endif
+	state->frontend.demodulator_priv = state;
+	state->vtunerc = vtunerc;
+	return &state->frontend;
+
+error:
+	kfree(state);
+	return NULL;
+}
+
+static struct dvb_frontend_ops dvb_proxyfe_qam_ops;
+
+static struct dvb_frontend *dvb_proxyfe_qam_attach(struct vtunerc_ctx *vtunerc)
+{
+	struct dvb_proxyfe_state *state = NULL;
+
+	/* allocate memory for the internal state */
+	state = kmalloc(sizeof(struct dvb_proxyfe_state), GFP_KERNEL);
+	if (state == NULL)
+		goto error;
+
+	/* create dvb_frontend */
+	memcpy(&state->frontend.ops, &dvb_proxyfe_qam_ops, sizeof(struct
dvb_frontend_ops));
+	state->frontend.demodulator_priv = state;
+	state->vtunerc = vtunerc;
+	return &state->frontend;
+
+error:
+	kfree(state);
+	return NULL;
+}
+
+static struct dvb_frontend_ops dvb_proxyfe_ofdm_ops = {
+
+	.info = {
+		.name			= "vTuner proxyFE DVB-T",
+		.type			= FE_OFDM,
+		.frequency_min		= 51000000,
+		.frequency_max		= 863250000,
+		.frequency_stepsize	= 62500,
+		.caps = FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 | FE_CAN_FEC_3_4 |
+				FE_CAN_FEC_4_5 | FE_CAN_FEC_5_6 | FE_CAN_FEC_6_7 |
+				FE_CAN_FEC_7_8 | FE_CAN_FEC_8_9 | FE_CAN_FEC_AUTO |
+				FE_CAN_QAM_16 | FE_CAN_QAM_64 | FE_CAN_QAM_AUTO |
+				FE_CAN_TRANSMISSION_MODE_AUTO |
+				FE_CAN_GUARD_INTERVAL_AUTO |
+				FE_CAN_HIERARCHY_AUTO,
+	},
+
+	.release = dvb_proxyfe_release,
+
+	.init = dvb_proxyfe_init,
+	.sleep = dvb_proxyfe_sleep,
+
+	.set_frontend = dvb_proxyfe_set_frontend,
+	.get_frontend = dvb_proxyfe_get_frontend,
+
+	.read_status = dvb_proxyfe_read_status,
+	.read_ber = dvb_proxyfe_read_ber,
+	.read_signal_strength = dvb_proxyfe_read_signal_strength,
+	.read_snr = dvb_proxyfe_read_snr,
+	.read_ucblocks = dvb_proxyfe_read_ucblocks,
+};
+
+static struct dvb_frontend_ops dvb_proxyfe_qam_ops = {
+
+	.info = {
+		.name			= "vTuner proxyFE DVB-C",
+		.type			= FE_QAM,
+		.frequency_stepsize	= 62500,
+		.frequency_min		= 51000000,
+		.frequency_max		= 858000000,
+		.symbol_rate_min	= (57840000/2)/64,     /* SACLK/64 == (XIN/2)/64 */
+		.symbol_rate_max	= (57840000/2)/4,      /* SACLK/4 */
+		.caps = FE_CAN_QAM_16 | FE_CAN_QAM_32 | FE_CAN_QAM_64 |
+			FE_CAN_QAM_128 | FE_CAN_QAM_256 |
+			FE_CAN_FEC_AUTO | FE_CAN_INVERSION_AUTO
+	},
+
+	.release = dvb_proxyfe_release,
+
+	.init = dvb_proxyfe_init,
+	.sleep = dvb_proxyfe_sleep,
+
+	.set_frontend = dvb_proxyfe_set_frontend,
+	.get_frontend = dvb_proxyfe_get_frontend,
+
+	.read_status = dvb_proxyfe_read_status,
+	.read_ber = dvb_proxyfe_read_ber,
+	.read_signal_strength = dvb_proxyfe_read_signal_strength,
+	.read_snr = dvb_proxyfe_read_snr,
+	.read_ucblocks = dvb_proxyfe_read_ucblocks,
+};
+
+static struct dvb_frontend_ops dvb_proxyfe_qpsk_ops = {
+
+	.info = {
+		.name			= "vTuner proxyFE DVB-S",
+		.type			= FE_QPSK,
+		.frequency_min		= 950000,
+		.frequency_max		= 2150000,
+		.frequency_stepsize	= 250,           /* kHz for QPSK frontends */
+		.frequency_tolerance	= 29500,
+		.symbol_rate_min	= 1000000,
+		.symbol_rate_max	= 45000000,
+		.caps = FE_CAN_INVERSION_AUTO |
+			FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 | FE_CAN_FEC_3_4 |
+			FE_CAN_FEC_5_6 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO |
+			FE_CAN_QPSK
+	},
+
+	.release = dvb_proxyfe_release,
+
+	.init = dvb_proxyfe_init,
+	.sleep = dvb_proxyfe_sleep,
+
+	.get_frontend = dvb_proxyfe_get_frontend,
+#if HAVE_DVB_API_VERSION >= 5
+	.get_property = dvb_proxyfe_get_property,
+	.get_frontend_algo = dvb_proxyfe_get_frontend_algo,
+	.set_frontend = dvb_proxyfe_set_frontend,
+#else
+	.set_frontend = dvb_proxyfe_set_frontend,
+#endif
+
+	.read_status = dvb_proxyfe_read_status,
+	.read_ber = dvb_proxyfe_read_ber,
+	.read_signal_strength = dvb_proxyfe_read_signal_strength,
+	.read_snr = dvb_proxyfe_read_snr,
+	.read_ucblocks = dvb_proxyfe_read_ucblocks,
+
+	.set_voltage = dvb_proxyfe_set_voltage,
+	.set_tone = dvb_proxyfe_set_tone,
+
+	.diseqc_send_master_cmd         = dvb_proxyfe_send_diseqc_msg,
+	.diseqc_send_burst              = dvb_proxyfe_send_diseqc_burst,
+
+};
+
+int /*__devinit*/ vtunerc_frontend_init(struct vtunerc_ctx *vtunerc)
+{
+	int ret;
+
+	if (vtunerc->fe) {
+		printk(PRINTK_NOTICE "%s: FE already initialized as type=%d\n",
__func__, vtunerc->vtype);
+		return 0;
+	}
+
+	switch (vtunerc->vtype) {
+	case VT_S:
+		vtunerc->fe = dvb_proxyfe_qpsk_attach(vtunerc, 0);
+		break;
+	case VT_S2:
+		vtunerc->fe = dvb_proxyfe_qpsk_attach(vtunerc, 1);
+		break;
+	case VT_T:
+		vtunerc->fe = dvb_proxyfe_ofdm_attach(vtunerc);
+		break;
+	case VT_C:
+		vtunerc->fe = dvb_proxyfe_qam_attach(vtunerc);
+		break;
+	default:
+		printk(PRINTK_ERR "%s unregognized tuner vtype = %d\n", __func__,
vtunerc->vtype);
+		return -EINVAL;
+	}
+	ret = dvb_register_frontend(&vtunerc->dvb_adapter, vtunerc->fe);
+
+	return 0;
+}
+
+int /*__devinit*/ vtunerc_frontend_clear(struct vtunerc_ctx *vtunerc)
+{
+	return vtunerc->fe ? dvb_unregister_frontend(vtunerc->fe) : 0;
+}

Re: [RFC] vtunerc - virtual DVB device driver

[Rémi Denis-Courmont]

	Hello,

Le dimanche 19 juin 2011 03:10:15 HoP, vous avez écrit :
> get inspired by (unfortunately close-source) solution on stb
> Dreambox 800 I have made my own implementation
> of virtual DVB device, based on the same device API.

Some might argue that CUSE can already do this. Then again, CUSE would not be 
able to reuse the kernel DVB core infrastructure: everything would need to be 
reinvented in userspace.

> In conjunction with "Dreamtuner" userland project
> [http://code.google.com/p/dreamtuner/] by Ronald Mieslinger
> user can create virtual DVB device on client side and connect it
> to the server. When connected, user is able to use any Linux DVB API
> compatible application on client side (like VDR, MeTV, MythTV, etc)
> without any need of code modification. As server can be used any
> Linux DVB API compatible device.

IMHO, this needs a Documentation file for the userspace API (kinda like 
tuntap.txt).

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis

Re: [RFC] vtunerc - virtual DVB device driver

[Devin Heitmueller]

2011/6/20 Rémi Denis-Courmont <remi@remlab.net>:
>        Hello,
>
> Le dimanche 19 juin 2011 03:10:15 HoP, vous avez écrit :
>> get inspired by (unfortunately close-source) solution on stb
>> Dreambox 800 I have made my own implementation
>> of virtual DVB device, based on the same device API.
>
> Some might argue that CUSE can already do this. Then again, CUSE would not be
> able to reuse the kernel DVB core infrastructure: everything would need to be
> reinvented in userspace.

Generally speaking, this is the key reason that "virtual dvb" drivers
have been rejected in the past for upstream inclusion - it makes it
easier for evil tuner manufacturers to leverage all the hard work done
by the LinuxTV developers while providing a closed-source solution.
It was an explicit goal to *not* allow third parties to reuse the
Linux DVB core unless they were providing in-kernel drivers which
conform to the GPL.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: [RFC] vtunerc - virtual DVB device driver

[HoP]

Hi Devin.

2011/6/20 Devin Heitmueller <dheitmueller@kernellabs.com>:
> 2011/6/20 Rémi Denis-Courmont <remi@remlab.net>:
>>        Hello,
>>
>> Le dimanche 19 juin 2011 03:10:15 HoP, vous avez écrit :
>>> get inspired by (unfortunately close-source) solution on stb
>>> Dreambox 800 I have made my own implementation
>>> of virtual DVB device, based on the same device API.
>>
>> Some might argue that CUSE can already do this. Then again, CUSE would not be
>> able to reuse the kernel DVB core infrastructure: everything would need to be
>> reinvented in userspace.
>
> Generally speaking, this is the key reason that "virtual dvb" drivers
> have been rejected in the past for upstream inclusion - it makes it

Can you tell me when such disscussion was done? I did a big attempt
to check if my work is not reinventing wheels, but I found only some
very generic frontend template by Emard <emard@softhome.net>.

> easier for evil tuner manufacturers to leverage all the hard work done
> by the LinuxTV developers while providing a closed-source solution.

May be I missunderstood something, but I can't see how frontend
virtualization/sharing can help to leverage others work.

> It was an explicit goal to *not* allow third parties to reuse the
> Linux DVB core unless they were providing in-kernel drivers which
> conform to the GPL.

I'm again not sure if you try to argument against vtunerc code
or nope.

Thanks

/Honza

Re: [RFC] vtunerc - virtual DVB device driver

[Devin Heitmueller]

On Mon, Jun 20, 2011 at 2:17 PM, HoP <jpetrous@gmail.com> wrote:
> Can you tell me when such disscussion was done? I did a big attempt
> to check if my work is not reinventing wheels, but I found only some
> very generic frontend template by Emard <emard@softhome.net>.

See the "userspace tuner" thread here for the background:

http://www.linuxtv.org/pipermail/linux-dvb/2007-August/thread.html#19840

>> easier for evil tuner manufacturers to leverage all the hard work done
>> by the LinuxTV developers while providing a closed-source solution.
>
> May be I missunderstood something, but I can't see how frontend
> virtualization/sharing can help to leverage others work.

It helps in that it allows third parties to write drivers in userspace
that leverage the in-kernel implementation of DVB core.  It means that
a product developer who didn't want to abide by the GPL could write a
closed-source driver in userland which takes advantage of the
thousands of lines of code that make up the DVB core.

>> It was an explicit goal to *not* allow third parties to reuse the
>> Linux DVB core unless they were providing in-kernel drivers which
>> conform to the GPL.
>
> I'm again not sure if you try to argument against vtunerc code
> or nope.

I am against things like this being in the upstream kernel which make
it easier for third parties to leverage GPL code without making their
code available under the GPL.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

RE: [RFC] vtunerc - virtual DVB device driver

[Sébastien RAILLARD (COEXSI)]

> -----Original Message-----
> From: linux-media-owner@vger.kernel.org [mailto:linux-media-
> owner@vger.kernel.org] On Behalf Of Devin Heitmueller
> Sent: lundi 20 juin 2011 20:25
> To: HoP
> Cc: Rémi Denis-Courmont; linux-media@vger.kernel.org
> Subject: Re: [RFC] vtunerc - virtual DVB device driver
> 
> On Mon, Jun 20, 2011 at 2:17 PM, HoP <jpetrous@gmail.com> wrote:
> > Can you tell me when such disscussion was done? I did a big attempt to
> > check if my work is not reinventing wheels, but I found only some very
> > generic frontend template by Emard <emard@softhome.net>.
> 
> See the "userspace tuner" thread here for the background:
> 
> http://www.linuxtv.org/pipermail/linux-dvb/2007-August/thread.html#19840
> 
> >> easier for evil tuner manufacturers to leverage all the hard work
> >> done by the LinuxTV developers while providing a closed-source
> solution.
> >
> > May be I missunderstood something, but I can't see how frontend
> > virtualization/sharing can help to leverage others work.
> 
> It helps in that it allows third parties to write drivers in userspace
> that leverage the in-kernel implementation of DVB core.  It means that a
> product developer who didn't want to abide by the GPL could write a
> closed-source driver in userland which takes advantage of the thousands
> of lines of code that make up the DVB core.
> 
> >> It was an explicit goal to *not* allow third parties to reuse the
> >> Linux DVB core unless they were providing in-kernel drivers which
> >> conform to the GPL.
> >
> > I'm again not sure if you try to argument against vtunerc code or
> > nope.
> 
> I am against things like this being in the upstream kernel which make it
> easier for third parties to leverage GPL code without making their code
> available under the GPL.
> 

If I may put my two cents in this discussion regarding the closed source
code problem: maybe it could be great to have some closed source drivers
making some DVB hardware working better or even allowing more DVB hardware
working under Linux. For example, there is a good support of PCI DVB
devices, but not yet so much support for PCIe DVB devices (and even less if
you're searching for DVB-S2 tuner with CAM support at reasonable price).
Also, most the DVB drivers code released under GPL is nearly impossible to
understand as there is no documentation (because of NDA agreements with
developers - as I understood) and no inline comments. So does-it make so
much difference with closed source code? I really don't want to aggress
anybody here, but it's really a question I have.
 
> Devin
> 
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
> --
> 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

Re: [RFC] vtunerc - virtual DVB device driver

[Devin Heitmueller]

2011/6/20 Sébastien RAILLARD (COEXSI) <sr@coexsi.fr>:
> If I may put my two cents in this discussion regarding the closed source
> code problem: maybe it could be great to have some closed source drivers
> making some DVB hardware working better or even allowing more DVB hardware
> working under Linux. For example, there is a good support of PCI DVB
> devices, but not yet so much support for PCIe DVB devices (and even less if
> you're searching for DVB-S2 tuner with CAM support at reasonable price).

Nothing prevents a third-party from writing closed source drivers.
What we do *not* think is fair though is that those third parties
should be able to take advantage of all the GPL code that makes up the
DVB core, and the man-years spent developing that code.

If somebody wants to write a closed source driver, they are welcome to
(in fact, some companies actually have).  But I'll be damned if
they're going to reuse GPL code to accomplish it.  They are welcome to
reimplement the DVB core in userland if that is their goal (under
whatever licensing terms suits them).

> Also, most the DVB drivers code released under GPL is nearly impossible to
> understand as there is no documentation (because of NDA agreements with
> developers - as I understood) and no inline comments. So does-it make so
> much difference with closed source code? I really don't want to aggress
> anybody here, but it's really a question I have.

I disagree with this assertion.  I have worked on *many* different
drivers in the DVB subsystem, most of them without having the
datasheets.  While having the datasheets definitely is helpful (and
can definitely speed up debugging), I would argue that they are not
essential.

Also, a number of the drivers are reverse engineered (no datasheets
from the vendor), which is why the registers are not documented (the
person writing the code didn't actually know).  While there are indeed
cases where an NDA specifically prohibited releasing a GPL driver that
contained the register names, this tends to be more the exception
rather than the rule.  All the drivers I have done with vendor
assistance/datasheets have allowed me to include register names in the
driver.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: [RFC] vtunerc - virtual DVB device driver

[Rémi Denis-Courmont]

	Hello again,

Le lundi 20 juin 2011 20:41:44 Devin Heitmueller, vous avez écrit :
> > Some might argue that CUSE can already do this. Then again, CUSE would
> > not be able to reuse the kernel DVB core infrastructure: everything
> > would need to be reinvented in userspace.
> 
> Generally speaking, this is the key reason that "virtual dvb" drivers
> have been rejected in the past for upstream inclusion - it makes it
> easier for evil tuner manufacturers to leverage all the hard work done

Err? My point is exactly the opposite: without a dedicated virtual DVB device, 
(open-source) developers are stuck with CUSE, which if it would work at all, 
would be a major waste of effort. And then, it won't work for unprivileged 
processes due to CUSE ioctl's restrictions.

In other words, my point was technical, not political.

> by the LinuxTV developers while providing a closed-source solution.

This does not enable much that evil closed-source device vendors couldn't 
already do. Virtually any Linux-DVB-capable tool will also accept MPEG-TS feed 
piped from standard input. Tuning would have to use a dedicated interface; 
that's pretty much the only inconvenience.

DVB_NET can be implemented with the TUNTAP driver easily if it comes to that. 
And remote control can be mulated with the uinput driver all the same. There 
is even a mem2mem V4L2 device nowadays, is there not? And while uinput and 
tuntap allow proprietary userspace drivers, they come with major limitations 
inherent to userspace which limit their usefulness for proprietary device 
drivers.

FWIW, virtual device driver enables (open-source) innovation. There are 
countless useful IP tunnels or emulators using TUN or TAP for instance.

> It was an explicit goal to *not* allow third parties to reuse the
> Linux DVB core unless they were providing in-kernel drivers which
> conform to the GPL.

I am afraid I don't understand how is Linux-DVB different from other Linux 
subsystems, such as the (much larger in terms of non-driver-specific code) 
networking one.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis

Re: [RFC] vtunerc - virtual DVB device driver

[HoP]

2011/6/20 Devin Heitmueller <dheitmueller@kernellabs.com>:
> 2011/6/20 Sébastien RAILLARD (COEXSI) <sr@coexsi.fr>:
>> If I may put my two cents in this discussion regarding the closed source
>> code problem: maybe it could be great to have some closed source drivers
>> making some DVB hardware working better or even allowing more DVB hardware
>> working under Linux. For example, there is a good support of PCI DVB
>> devices, but not yet so much support for PCIe DVB devices (and even less if
>> you're searching for DVB-S2 tuner with CAM support at reasonable price).
>
> Nothing prevents a third-party from writing closed source drivers.
> What we do *not* think is fair though is that those third parties
> should be able to take advantage of all the GPL code that makes up the
> DVB core, and the man-years spent developing that code.
>
> If somebody wants to write a closed source driver, they are welcome to
> (in fact, some companies actually have).  But I'll be damned if
> they're going to reuse GPL code to accomplish it.  They are welcome to
> reimplement the DVB core in userland if that is their goal (under
> whatever licensing terms suits them).
>

Do you think it is really serious enough reason to prevent of having
such virtualization driver in the kernel?

Let check my situation and tell me how I should continue (TBH, I already
thought that driver can be accepted, but my dumb brain thought because
of non quality code/design or so. It was really big "surprise" which
reason was used aginst it):

I have equipment, based of course on Linux and others open-source
code, which is using DVB tuners sharing (the box has two DVB-S2 NIMs
on inputs and ethernet on output). If I understand you well, I have to cut
such box feature (which is, btw, one of very nicer usecase of such box)
and stop thinking about it?

Do you really think that it is a good way which should linux come?
I don't like binary drivers as well. But if developers can't extend
usability of linux because of worrying about blob drivers, it is not
good, it is path to the hell.

My 2cents.

/Honza

PS: I don't want to start any war, but I would like to know if it is only
Devin POV or it has wider support inside linux-media hackers.
Of course I will stay with my drivers outside the kernel. Ugly, I know.
But I never want to enter by closed doors. Not my way.

Re: [RFC] vtunerc - virtual DVB device driver

[Devin Heitmueller]

On Mon, Jun 20, 2011 at 3:56 PM, HoP <jpetrous@gmail.com> wrote:
> Do you think it is really serious enough reason to prevent of having
> such virtualization driver in the kernel?
>
> Let check my situation and tell me how I should continue (TBH, I already
> thought that driver can be accepted, but my dumb brain thought because
> of non quality code/design or so. It was really big "surprise" which
> reason was used aginst it):

Yes, this is entirely a political issue and not a technical one.
Every couple of years somebody implements such a driver, and they have
all been rejected for upstream.

> I have equipment, based of course on Linux and others open-source
> code, which is using DVB tuners sharing (the box has two DVB-S2 NIMs
> on inputs and ethernet on output). If I understand you well, I have to cut
> such box feature (which is, btw, one of very nicer usecase of such box)
> and stop thinking about it?
>
> Do you really think that it is a good way which should linux come?
> I don't like binary drivers as well. But if developers can't extend
> usability of linux because of worrying about blob drivers, it is not
> good, it is path to the hell.

The unfortunate fact is that allowing this sort of thing *does* allow
for abuse of the interface, even if was not the intention of the
original author of the patch/driver.  In fact, I believe all the cases
in the past were by people who were friendly to open source.

> My 2cents.
>
> /Honza
>
> PS: I don't want to start any war, but I would like to know if it is only
> Devin POV or it has wider support inside linux-media hackers.
> Of course I will stay with my drivers outside the kernel. Ugly, I know.
> But I never want to enter by closed doors. Not my way.

To be fair, I am not the originator of this argument.  If you read the
history, a variety of other Linux DVB-V4L developers have shared the
same view (which I adopted after hearing the arguments).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: [RFC] vtunerc - virtual DVB device driver

[HoP]

2011/6/20 Devin Heitmueller <dheitmueller@kernellabs.com>:
> On Mon, Jun 20, 2011 at 3:56 PM, HoP <jpetrous@gmail.com> wrote:
>> Do you think it is really serious enough reason to prevent of having
>> such virtualization driver in the kernel?
>>
>> Let check my situation and tell me how I should continue (TBH, I already
>> thought that driver can be accepted, but my dumb brain thought because
>> of non quality code/design or so. It was really big "surprise" which
>> reason was used aginst it):
>
> Yes, this is entirely a political issue and not a technical one.

Political? So we can declare that politics win (again) technicians. Sad.

> Every couple of years somebody implements such a driver, and they have
> all been rejected for upstream.

Why same not apply to other devices? If I would be really accurate
I would vote for removing nfs, smbfs and all other network sharing filesystems.

> original author of the patch/driver.  In fact, I believe all the cases
> in the past were by people who were friendly to open source.

I would like to know how much such "bad guys" stayed with kernel
development.

> To be fair, I am not the originator of this argument.  If you read the
> history, a variety of other Linux DVB-V4L developers have shared the
> same view (which I adopted after hearing the arguments).

Seems DVB hackers are very specific group. Such politic rule
don't wan't to have any place in the code development. Of course,
it's my personal opinion only.

/Honza

Re: [RFC] vtunerc - virtual DVB device driver

[Mauro Carvalho Chehab]

Em 20-06-2011 17:24, HoP escreveu:
> 2011/6/20 Devin Heitmueller <dheitmueller@kernellabs.com>:
>> On Mon, Jun 20, 2011 at 3:56 PM, HoP <jpetrous@gmail.com> wrote:
>>> Do you think it is really serious enough reason to prevent of having
>>> such virtualization driver in the kernel?
>>>
>>> Let check my situation and tell me how I should continue (TBH, I already
>>> thought that driver can be accepted, but my dumb brain thought because
>>> of non quality code/design or so. It was really big "surprise" which
>>> reason was used aginst it):
>>
>> Yes, this is entirely a political issue and not a technical one.
> 
> Political? So we can declare that politics win (again) technicians. Sad.

This is not a political issue. It is a licensing issue. If you want to use
someone's else code, you need to accept the licensing terms that the developers
are giving you, by either paying the price for the code usage (on closed source
licensing models), or by accepting the license when using an open-sourced code.

Preserving the open-source eco-system is something that everyone
developing open source expect: basically, you're free to do whatever
you want, but if you're using a code written by an open-source developer,
the expected behaviour that GPL asks (and that the developer wants, when he
opted for GPL) is that you should return back to the community with any 
changes you did, including derivative work. This is an essential rule of working
with GPL.

If you're not happy with that, that's fine. You can implement another stack 
that is not GPL-licensed.

Mauro.

Re: [RFC] vtunerc - virtual DVB device driver

[HoP]

2011/6/20 Mauro Carvalho Chehab <mchehab@redhat.com>:
> Em 20-06-2011 17:24, HoP escreveu:
>> 2011/6/20 Devin Heitmueller <dheitmueller@kernellabs.com>:
>>> On Mon, Jun 20, 2011 at 3:56 PM, HoP <jpetrous@gmail.com> wrote:
>>>> Do you think it is really serious enough reason to prevent of having
>>>> such virtualization driver in the kernel?
>>>>
>>>> Let check my situation and tell me how I should continue (TBH, I already
>>>> thought that driver can be accepted, but my dumb brain thought because
>>>> of non quality code/design or so. It was really big "surprise" which
>>>> reason was used aginst it):
>>>
>>> Yes, this is entirely a political issue and not a technical one.
>>
>> Political? So we can declare that politics win (again) technicians. Sad.
>
> This is not a political issue. It is a licensing issue. If you want to use
> someone's else code, you need to accept the licensing terms that the developers
> are giving you, by either paying the price for the code usage (on closed source
> licensing models), or by accepting the license when using an open-sourced code.
>
> Preserving the open-source eco-system is something that everyone
> developing open source expect: basically, you're free to do whatever
> you want, but if you're using a code written by an open-source developer,
> the expected behaviour that GPL asks (and that the developer wants, when he
> opted for GPL) is that you should return back to the community with any
> changes you did, including derivative work. This is an essential rule of working
> with GPL.
>
> If you're not happy with that, that's fine. You can implement another stack
> that is not GPL-licensed.

Mauro, you totally misunderstood me. If you see on my first post in that thread
I was sending full GPL-ed driver to the mailinglist.

I simply didn't expect that my source will be refused because of worrying
about misuse it to the bad things(tm).

Note again: I did it GPLed and opensourced, I never ever thought about
binary blobs or some other closed stuffs!

/Honza

Re: [RFC] vtunerc - virtual DVB device driver

[Bjørn Mork]

Devin Heitmueller <dheitmueller@kernellabs.com> writes:

> Nothing prevents a third-party from writing closed source drivers.
> What we do *not* think is fair though is that those third parties
> should be able to take advantage of all the GPL code that makes up the
> DVB core, and the man-years spent developing that code.

You could use the same argument against adding a loadable module
interface to the Linux kernel (and I'm pretty sure it was used).
Thankfully, usability won back then.  Or we most likely wouldn't have
had a single Linux DVB driver.  Or Linux at all, except as a historical
footnote.

Honza posted a GPL licensed driver and gave a pretty good usage
scenario.  Please don't reject it based on fear of abuse.  If you think
about it, almost any usability improvement will also make abuse easier.
And if you reject all of them based on such fear, then your system will
die.


Thanks.


Bjørn

Re: [RFC] vtunerc - virtual DVB device driver

[HoP]

Hi Bjørn.

2011/6/21 Bjørn Mork <bjorn@mork.no>:
> Devin Heitmueller <dheitmueller@kernellabs.com> writes:
>
>> Nothing prevents a third-party from writing closed source drivers.
>> What we do *not* think is fair though is that those third parties
>> should be able to take advantage of all the GPL code that makes up the
>> DVB core, and the man-years spent developing that code.
>
> You could use the same argument against adding a loadable module
> interface to the Linux kernel (and I'm pretty sure it was used).
> Thankfully, usability won back then.  Or we most likely wouldn't have
> had a single Linux DVB driver.  Or Linux at all, except as a historical
> footnote.
>
> Honza posted a GPL licensed driver and gave a pretty good usage
> scenario.  Please don't reject it based on fear of abuse.  If you think
> about it, almost any usability improvement will also make abuse easier.
> And if you reject all of them based on such fear, then your system will
> die.

Thank you for you support. Until now I thought that my non-understanding
of that "abuse-fearing-rule" was only my own brain defect :-)

So, linux-media guys, don't worry. Because vtunerc is my very first kernel
code I can assure you that you find most likely some design defects
or something like that what prevent of code upstreaming. It can take loooong
time until the code will grow up for upstreaming :-)

/Honza

PS: The driver is in use for more then 6 months with VDR.

Re: [RFC] vtunerc - virtual DVB device driver

[Devin Heitmueller]

On Mon, Jun 20, 2011 at 6:11 PM, Bjørn Mork <bjorn@mork.no> wrote:
> Devin Heitmueller <dheitmueller@kernellabs.com> writes:
>
>> Nothing prevents a third-party from writing closed source drivers.
>> What we do *not* think is fair though is that those third parties
>> should be able to take advantage of all the GPL code that makes up the
>> DVB core, and the man-years spent developing that code.
>
> You could use the same argument against adding a loadable module
> interface to the Linux kernel (and I'm pretty sure it was used).
> Thankfully, usability won back then.  Or we most likely wouldn't have
> had a single Linux DVB driver.  Or Linux at all, except as a historical
> footnote.
>
> Honza posted a GPL licensed driver and gave a pretty good usage
> scenario.  Please don't reject it based on fear of abuse.  If you think
> about it, almost any usability improvement will also make abuse easier.
> And if you reject all of them based on such fear, then your system will
> die.

There isn't much sense in having this discussion again (and kicking
off yet another flamewar).  All of your arguments have been made
before (and in the case of Linux DVB, they failed).  I would suggest
you read the archives and see how the developers arrived at their
conclusions.

If you have some *new* argument to offer, then feel free.  Otherwise
it's just flamebait.

Anyway, I've said what I have to say on this topic.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: [RFC] vtunerc - virtual DVB device driver

[Mauro Carvalho Chehab]

Em 20-06-2011 18:31, HoP escreveu:
> 2011/6/20 Mauro Carvalho Chehab <mchehab@redhat.com>:
>> Em 20-06-2011 17:24, HoP escreveu:
>>> 2011/6/20 Devin Heitmueller <dheitmueller@kernellabs.com>:
>>>> On Mon, Jun 20, 2011 at 3:56 PM, HoP <jpetrous@gmail.com> wrote:
>>>>> Do you think it is really serious enough reason to prevent of having
>>>>> such virtualization driver in the kernel?
>>>>>
>>>>> Let check my situation and tell me how I should continue (TBH, I already
>>>>> thought that driver can be accepted, but my dumb brain thought because
>>>>> of non quality code/design or so. It was really big "surprise" which
>>>>> reason was used aginst it):
>>>>
>>>> Yes, this is entirely a political issue and not a technical one.
>>>
>>> Political? So we can declare that politics win (again) technicians. Sad.
>>
>> This is not a political issue. It is a licensing issue. If you want to use
>> someone's else code, you need to accept the licensing terms that the developers
>> are giving you, by either paying the price for the code usage (on closed source
>> licensing models), or by accepting the license when using an open-sourced code.
>>
>> Preserving the open-source eco-system is something that everyone
>> developing open source expect: basically, you're free to do whatever
>> you want, but if you're using a code written by an open-source developer,
>> the expected behaviour that GPL asks (and that the developer wants, when he
>> opted for GPL) is that you should return back to the community with any
>> changes you did, including derivative work. This is an essential rule of working
>> with GPL.
>>
>> If you're not happy with that, that's fine. You can implement another stack
>> that is not GPL-licensed.
> 
> Mauro, you totally misunderstood me. If you see on my first post in that thread
> I was sending full GPL-ed driver to the mailinglist.

You misunderstood me. Something that exposes the kernel interface to for an
userspace client driver to implement DVB is not a driver, it is a wrapper.

The real driver will be in userspace, using the DVB stack, and can even be
closed source. Some developers already tried to do things like that and sell
the userspace code. Such code submission were nacked. There is even one case
where the kernelspace code were dropped due to that (and later, replaced by an
opensource driver).

We don't want to go on this way again.

Mauro.

Re: [RFC] vtunerc - virtual DVB device driver

[Andreas Oberritter]

On 06/21/2011 03:35 AM, Mauro Carvalho Chehab wrote:
> Em 20-06-2011 18:31, HoP escreveu:
>> 2011/6/20 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>> Em 20-06-2011 17:24, HoP escreveu:
>>>> 2011/6/20 Devin Heitmueller <dheitmueller@kernellabs.com>:
>>>>> On Mon, Jun 20, 2011 at 3:56 PM, HoP <jpetrous@gmail.com> wrote:
>>>>>> Do you think it is really serious enough reason to prevent of having
>>>>>> such virtualization driver in the kernel?
>>>>>>
>>>>>> Let check my situation and tell me how I should continue (TBH, I already
>>>>>> thought that driver can be accepted, but my dumb brain thought because
>>>>>> of non quality code/design or so. It was really big "surprise" which
>>>>>> reason was used aginst it):
>>>>>
>>>>> Yes, this is entirely a political issue and not a technical one.
>>>>
>>>> Political? So we can declare that politics win (again) technicians. Sad.
>>>
>>> This is not a political issue. It is a licensing issue. If you want to use
>>> someone's else code, you need to accept the licensing terms that the developers
>>> are giving you, by either paying the price for the code usage (on closed source
>>> licensing models), or by accepting the license when using an open-sourced code.
>>>
>>> Preserving the open-source eco-system is something that everyone
>>> developing open source expect: basically, you're free to do whatever
>>> you want, but if you're using a code written by an open-source developer,
>>> the expected behaviour that GPL asks (and that the developer wants, when he
>>> opted for GPL) is that you should return back to the community with any
>>> changes you did, including derivative work. This is an essential rule of working
>>> with GPL.
>>>
>>> If you're not happy with that, that's fine. You can implement another stack
>>> that is not GPL-licensed.
>>
>> Mauro, you totally misunderstood me. If you see on my first post in that thread
>> I was sending full GPL-ed driver to the mailinglist.
> 
> You misunderstood me. Something that exposes the kernel interface to for an
> userspace client driver to implement DVB is not a driver, it is a wrapper.
> 
> The real driver will be in userspace, using the DVB stack, and can even be
> closed source. Some developers already tried to do things like that and sell
> the userspace code. Such code submission were nacked. There is even one case
> where the kernelspace code were dropped due to that (and later, replaced by an
> opensource driver).
> 
> We don't want to go on this way again.

Mauro and Devin, I think you're missing the point. This is not about
creating drivers in userspace. This is not about open or closed source.
The "vtuner" interface, as implemented for the Dreambox, is used to
access remote tuners: Put x tuners into y boxes and access them from
another box as if they were local. It's used in conjunction with further
software to receive the transport stream over a network connection.
Honza's code does the same thing.

You don't need it in order to create closed source drivers. You can
already create closed kernel drivers now. Also, you can create tuner
drivers in userspace using the i2c-dev interface. If you like to connect
a userspace driver to a DVB API device node, you can distribute a small
(open or closed) wrapper with it. So what are you arguing about?
Everything you're feared of can already be done since virtually forever.

If you're feared of exposing kernel interfaces to userspace, then I
think your only option is to remove the whole userspace. You might want
to remove i2c-dev and the loadable module interface first.

Regarding the code, Honza, I think the interface is neither clean nor
generic enough to be included in the kernel. It doesn't make much sense
to stay compatible to the interface used by the Dreambox. This interface
evolved from very old versions of the DVB API and therefore carries way
too much cruft and hacks for a shiny new interface. As a side note: Your
ioctl constants already differ from the original vtuner code.

IMO, at least these steps need to be taken:
- Remove unused code. You already mentioned it, but it really should be
removed before submitting code, because it makes review much harder.
- Remove redefined structs and constants.
- Drop support for anything older than S2API.
- Define a way to use an existing demux instead of registering a new
software demux. On hardware that supports it, an input channel should be
allocated for each vtuner, in order to use the hardware's filtering and
decoding capabilities.
- Drop VTUNER_SET_NAME, VTUNER_SET_HAS_OUTPUTS, VTUNER_SET_MODES,
VTUNER_SET_TYPE and VTUNER_SET_NUM_MODES. They are all either specific
to the Dreambox or already obsoleted by S2API commands or should be
implemented as new S2API commands.

Regards,
Andreas

Re: [RFC] vtunerc - virtual DVB device driver

[HoP]

[-- Attachment #1: Type: text/plain, Size: 2817 bytes --]

2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
> Em 20-06-2011 18:31, HoP escreveu:
>> 2011/6/20 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>> Em 20-06-2011 17:24, HoP escreveu:
>>>> 2011/6/20 Devin Heitmueller <dheitmueller@kernellabs.com>:
>>>>> On Mon, Jun 20, 2011 at 3:56 PM, HoP <jpetrous@gmail.com> wrote:
>>>>>> Do you think it is really serious enough reason to prevent of having
>>>>>> such virtualization driver in the kernel?
>>>>>>
>>>>>> Let check my situation and tell me how I should continue (TBH, I already
>>>>>> thought that driver can be accepted, but my dumb brain thought because
>>>>>> of non quality code/design or so. It was really big "surprise" which
>>>>>> reason was used aginst it):
>>>>>
>>>>> Yes, this is entirely a political issue and not a technical one.
>>>>
>>>> Political? So we can declare that politics win (again) technicians. Sad.
>>>
>>> This is not a political issue. It is a licensing issue. If you want to use
>>> someone's else code, you need to accept the licensing terms that the developers
>>> are giving you, by either paying the price for the code usage (on closed source
>>> licensing models), or by accepting the license when using an open-sourced code.
>>>
>>> Preserving the open-source eco-system is something that everyone
>>> developing open source expect: basically, you're free to do whatever
>>> you want, but if you're using a code written by an open-source developer,
>>> the expected behaviour that GPL asks (and that the developer wants, when he
>>> opted for GPL) is that you should return back to the community with any
>>> changes you did, including derivative work. This is an essential rule of working
>>> with GPL.
>>>
>>> If you're not happy with that, that's fine. You can implement another stack
>>> that is not GPL-licensed.
>>
>> Mauro, you totally misunderstood me. If you see on my first post in that thread
>> I was sending full GPL-ed driver to the mailinglist.
>
> You misunderstood me. Something that exposes the kernel interface to for an
> userspace client driver to implement DVB is not a driver, it is a wrapper.
>
> The real driver will be in userspace, using the DVB stack, and can even be
> closed source. Some developers already tried to do things like that and sell
> the userspace code. Such code submission were nacked. There is even one case
> where the kernelspace code were dropped due to that (and later, replaced by an
> opensource driver).

No, you are again wrong, sorry.

If you ever tried to understand my small schema and description, you would
find that REAL drivers remeains in kernel. May be you understand what
I want from attached picture. You can see that the driver acts as bridge
(ok, you like wording "wrapper" so) to distribute remote driver functionality
down to the client and back.

/Honza

[-- Attachment #2: vtuner-small-picture.png --]
[-- Type: image/png, Size: 21704 bytes --]

Re: [RFC] vtunerc - virtual DVB device driver

[Mauro Carvalho Chehab]

Em 21-06-2011 08:04, Andreas Oberritter escreveu:
> On 06/21/2011 03:35 AM, Mauro Carvalho Chehab wrote:
>> Em 20-06-2011 18:31, HoP escreveu:
>>> 2011/6/20 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>> Em 20-06-2011 17:24, HoP escreveu:
>>>>> 2011/6/20 Devin Heitmueller <dheitmueller@kernellabs.com>:
>>>>>> On Mon, Jun 20, 2011 at 3:56 PM, HoP <jpetrous@gmail.com> wrote:
>>>>>>> Do you think it is really serious enough reason to prevent of having
>>>>>>> such virtualization driver in the kernel?
>>>>>>>
>>>>>>> Let check my situation and tell me how I should continue (TBH, I already
>>>>>>> thought that driver can be accepted, but my dumb brain thought because
>>>>>>> of non quality code/design or so. It was really big "surprise" which
>>>>>>> reason was used aginst it):
>>>>>>
>>>>>> Yes, this is entirely a political issue and not a technical one.
>>>>>
>>>>> Political? So we can declare that politics win (again) technicians. Sad.
>>>>
>>>> This is not a political issue. It is a licensing issue. If you want to use
>>>> someone's else code, you need to accept the licensing terms that the developers
>>>> are giving you, by either paying the price for the code usage (on closed source
>>>> licensing models), or by accepting the license when using an open-sourced code.
>>>>
>>>> Preserving the open-source eco-system is something that everyone
>>>> developing open source expect: basically, you're free to do whatever
>>>> you want, but if you're using a code written by an open-source developer,
>>>> the expected behaviour that GPL asks (and that the developer wants, when he
>>>> opted for GPL) is that you should return back to the community with any
>>>> changes you did, including derivative work. This is an essential rule of working
>>>> with GPL.
>>>>
>>>> If you're not happy with that, that's fine. You can implement another stack
>>>> that is not GPL-licensed.
>>>
>>> Mauro, you totally misunderstood me. If you see on my first post in that thread
>>> I was sending full GPL-ed driver to the mailinglist.
>>
>> You misunderstood me. Something that exposes the kernel interface to for an
>> userspace client driver to implement DVB is not a driver, it is a wrapper.
>>
>> The real driver will be in userspace, using the DVB stack, and can even be
>> closed source. Some developers already tried to do things like that and sell
>> the userspace code. Such code submission were nacked. There is even one case
>> where the kernelspace code were dropped due to that (and later, replaced by an
>> opensource driver).
>>
>> We don't want to go on this way again.
> 
> Mauro and Devin, I think you're missing the point. This is not about
> creating drivers in userspace. This is not about open or closed source.
> The "vtuner" interface, as implemented for the Dreambox, is used to
> access remote tuners: Put x tuners into y boxes and access them from
> another box as if they were local. It's used in conjunction with further
> software to receive the transport stream over a network connection.
> Honza's code does the same thing.
> 
> You don't need it in order to create closed source drivers. You can
> already create closed kernel drivers now. Also, you can create tuner
> drivers in userspace using the i2c-dev interface. If you like to connect
> a userspace driver to a DVB API device node, you can distribute a small
> (open or closed) wrapper with it. So what are you arguing about?
> Everything you're feared of can already be done since virtually forever.

Yes, but we don't need to review/maintain a kernel driver meant to be
used by closed source applications, and, if they're using a GPL'd code
inside a closed source application, they can be sued.

I didn't review the patchset, but, from the description, I understood that
it were developed to use some Dreambox-specific closed source applications.
With such requirement, for me it is just a wrapper to some closed source
application.

That's said, I'm not against a driver that allows using a DVB kernel
driver by a DVB open source application either inside a virtual machine
or on a remote machine. This seems useful for me. So, if the code could
be turned into it, I'll review and consider for its inclusion upstream.

For that to happen, it should not try to use any Dreambox specific application
or protocol, but to just use the standard DVBv5 API, as you've pointed.

> If you're feared of exposing kernel interfaces to userspace, then I
> think your only option is to remove the whole userspace. You might want
> to remove i2c-dev and the loadable module interface first.
> 
> Regarding the code, Honza, I think the interface is neither clean nor
> generic enough to be included in the kernel. It doesn't make much sense
> to stay compatible to the interface used by the Dreambox. This interface
> evolved from very old versions of the DVB API and therefore carries way
> too much cruft and hacks for a shiny new interface. As a side note: Your
> ioctl constants already differ from the original vtuner code.
> 
> IMO, at least these steps need to be taken:
> - Remove unused code. You already mentioned it, but it really should be
> removed before submitting code, because it makes review much harder.
> - Remove redefined structs and constants.
> - Drop support for anything older than S2API.
> - Define a way to use an existing demux instead of registering a new
> software demux. On hardware that supports it, an input channel should be
> allocated for each vtuner, in order to use the hardware's filtering and
> decoding capabilities.
> - Drop VTUNER_SET_NAME, VTUNER_SET_HAS_OUTPUTS, VTUNER_SET_MODES,
> VTUNER_SET_TYPE and VTUNER_SET_NUM_MODES. They are all either specific
> to the Dreambox or already obsoleted by S2API commands or should be
> implemented as new S2API commands.
> 
> Regards,
> Andreas

Re: [RFC] vtunerc - virtual DVB device driver

[Andreas Oberritter]

On 06/21/2011 02:05 PM, Mauro Carvalho Chehab wrote:
> Em 21-06-2011 08:04, Andreas Oberritter escreveu:
>> On 06/21/2011 03:35 AM, Mauro Carvalho Chehab wrote:
>>> Em 20-06-2011 18:31, HoP escreveu:
>>>> 2011/6/20 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>>> Em 20-06-2011 17:24, HoP escreveu:
>>>>>> 2011/6/20 Devin Heitmueller <dheitmueller@kernellabs.com>:
>>>>>>> On Mon, Jun 20, 2011 at 3:56 PM, HoP <jpetrous@gmail.com> wrote:
>>>>>>>> Do you think it is really serious enough reason to prevent of having
>>>>>>>> such virtualization driver in the kernel?
>>>>>>>>
>>>>>>>> Let check my situation and tell me how I should continue (TBH, I already
>>>>>>>> thought that driver can be accepted, but my dumb brain thought because
>>>>>>>> of non quality code/design or so. It was really big "surprise" which
>>>>>>>> reason was used aginst it):
>>>>>>>
>>>>>>> Yes, this is entirely a political issue and not a technical one.
>>>>>>
>>>>>> Political? So we can declare that politics win (again) technicians. Sad.
>>>>>
>>>>> This is not a political issue. It is a licensing issue. If you want to use
>>>>> someone's else code, you need to accept the licensing terms that the developers
>>>>> are giving you, by either paying the price for the code usage (on closed source
>>>>> licensing models), or by accepting the license when using an open-sourced code.
>>>>>
>>>>> Preserving the open-source eco-system is something that everyone
>>>>> developing open source expect: basically, you're free to do whatever
>>>>> you want, but if you're using a code written by an open-source developer,
>>>>> the expected behaviour that GPL asks (and that the developer wants, when he
>>>>> opted for GPL) is that you should return back to the community with any
>>>>> changes you did, including derivative work. This is an essential rule of working
>>>>> with GPL.
>>>>>
>>>>> If you're not happy with that, that's fine. You can implement another stack
>>>>> that is not GPL-licensed.
>>>>
>>>> Mauro, you totally misunderstood me. If you see on my first post in that thread
>>>> I was sending full GPL-ed driver to the mailinglist.
>>>
>>> You misunderstood me. Something that exposes the kernel interface to for an
>>> userspace client driver to implement DVB is not a driver, it is a wrapper.
>>>
>>> The real driver will be in userspace, using the DVB stack, and can even be
>>> closed source. Some developers already tried to do things like that and sell
>>> the userspace code. Such code submission were nacked. There is even one case
>>> where the kernelspace code were dropped due to that (and later, replaced by an
>>> opensource driver).
>>>
>>> We don't want to go on this way again.
>>
>> Mauro and Devin, I think you're missing the point. This is not about
>> creating drivers in userspace. This is not about open or closed source.
>> The "vtuner" interface, as implemented for the Dreambox, is used to
>> access remote tuners: Put x tuners into y boxes and access them from
>> another box as if they were local. It's used in conjunction with further
>> software to receive the transport stream over a network connection.
>> Honza's code does the same thing.
>>
>> You don't need it in order to create closed source drivers. You can
>> already create closed kernel drivers now. Also, you can create tuner
>> drivers in userspace using the i2c-dev interface. If you like to connect
>> a userspace driver to a DVB API device node, you can distribute a small
>> (open or closed) wrapper with it. So what are you arguing about?
>> Everything you're feared of can already be done since virtually forever.
> 
> Yes, but we don't need to review/maintain a kernel driver meant to be
> used by closed source applications

*Not that it would apply to this case*, but disallowing closed source
applications in userspace is ridiculous. And why should you reject a
possibly nice interface just because no open source application using it
has already been written?

> and, if they're using a GPL'd code
> inside a closed source application, they can be sued.
> 
> I didn't review the patchset, but, from the description, I understood that
> it were developed to use some Dreambox-specific closed source applications.
> With such requirement, for me it is just a wrapper to some closed source
> application.

I see. That's where you're wrong. Neither does it depend on any closed
application (Honza even included the link to the source code of the
application: https://code.google.com/p/dreamtuner/), nor is this
application specific to the Dreambox. The Dreambox is just the origin of
the vtuner API.

Btw.: Honza repeatedly stated that he's using his code with VDR, which
in other words means that he's not using a Dreambox.

> That's said, I'm not against a driver that allows using a DVB kernel
> driver by a DVB open source application either inside a virtual machine
> or on a remote machine. This seems useful for me. So, if the code could
> be turned into it, I'll review and consider for its inclusion upstream.

You mean, if the code could be turned into what it already is?

> For that to happen, it should not try to use any Dreambox specific application
> or protocol, but to just use the standard DVBv5 API, as you've pointed.

The DVB API v5 (as of now) is a set of character devices with associated
commands. Vtuner is a way to create such (virtual, frontend) character
devices and intercept and relay their commands. You cannot use DVB API
v5 commands to create a character device, unless of course you integrate
vtuner (or something similar) into the DVB API v5 first.

What I pointed out was that the number of commands of the current vtuner
API can and should be reduced (by using or adding S2API properties,
which in turn get relayed through the vtuner API).

Regards,
Andreas

Re: [RFC] vtunerc - virtual DVB device driver

[HoP]

2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
> Em 21-06-2011 08:04, Andreas Oberritter escreveu:
>> On 06/21/2011 03:35 AM, Mauro Carvalho Chehab wrote:
>>> Em 20-06-2011 18:31, HoP escreveu:
>>>> 2011/6/20 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>>> Em 20-06-2011 17:24, HoP escreveu:
>>>>>> 2011/6/20 Devin Heitmueller <dheitmueller@kernellabs.com>:
>>>>>>> On Mon, Jun 20, 2011 at 3:56 PM, HoP <jpetrous@gmail.com> wrote:
>>>>>>>> Do you think it is really serious enough reason to prevent of having
>>>>>>>> such virtualization driver in the kernel?
>>>>>>>>
>>>>>>>> Let check my situation and tell me how I should continue (TBH, I already
>>>>>>>> thought that driver can be accepted, but my dumb brain thought because
>>>>>>>> of non quality code/design or so. It was really big "surprise" which
>>>>>>>> reason was used aginst it):
>>>>>>>
>>>>>>> Yes, this is entirely a political issue and not a technical one.
>>>>>>
>>>>>> Political? So we can declare that politics win (again) technicians. Sad.
>>>>>
>>>>> This is not a political issue. It is a licensing issue. If you want to use
>>>>> someone's else code, you need to accept the licensing terms that the developers
>>>>> are giving you, by either paying the price for the code usage (on closed source
>>>>> licensing models), or by accepting the license when using an open-sourced code.
>>>>>
>>>>> Preserving the open-source eco-system is something that everyone
>>>>> developing open source expect: basically, you're free to do whatever
>>>>> you want, but if you're using a code written by an open-source developer,
>>>>> the expected behaviour that GPL asks (and that the developer wants, when he
>>>>> opted for GPL) is that you should return back to the community with any
>>>>> changes you did, including derivative work. This is an essential rule of working
>>>>> with GPL.
>>>>>
>>>>> If you're not happy with that, that's fine. You can implement another stack
>>>>> that is not GPL-licensed.
>>>>
>>>> Mauro, you totally misunderstood me. If you see on my first post in that thread
>>>> I was sending full GPL-ed driver to the mailinglist.
>>>
>>> You misunderstood me. Something that exposes the kernel interface to for an
>>> userspace client driver to implement DVB is not a driver, it is a wrapper.
>>>
>>> The real driver will be in userspace, using the DVB stack, and can even be
>>> closed source. Some developers already tried to do things like that and sell
>>> the userspace code. Such code submission were nacked. There is even one case
>>> where the kernelspace code were dropped due to that (and later, replaced by an
>>> opensource driver).
>>>
>>> We don't want to go on this way again.
>>
>> Mauro and Devin, I think you're missing the point. This is not about
>> creating drivers in userspace. This is not about open or closed source.
>> The "vtuner" interface, as implemented for the Dreambox, is used to
>> access remote tuners: Put x tuners into y boxes and access them from
>> another box as if they were local. It's used in conjunction with further
>> software to receive the transport stream over a network connection.
>> Honza's code does the same thing.
>>
>> You don't need it in order to create closed source drivers. You can
>> already create closed kernel drivers now. Also, you can create tuner
>> drivers in userspace using the i2c-dev interface. If you like to connect
>> a userspace driver to a DVB API device node, you can distribute a small
>> (open or closed) wrapper with it. So what are you arguing about?
>> Everything you're feared of can already be done since virtually forever.
>
> Yes, but we don't need to review/maintain a kernel driver meant to be
> used by closed source applications, and, if they're using a GPL'd code
> inside a closed source application, they can be sued.

Well, seems you are trying to argue using wrong arguments.
One more again: If you follow my picture - all on the path,
INCLUDING userland application, is GPL code. If you think
about Enigma, it is GPLed also, at least version 1. But my driver
is not for dreamboxes! They have similar implementation already
included there. My intention was different: to allow same thing
like is possible with dreamboxes, on "normal" linux PC desktop.
Using any other userland DVB application, like VDR or MythTV or vlc.
Got my point? I have nothing to do with any closed source or even
binary blobs! I want DVB adapter distribution across network,
nothing more. Everything is clear, from GPL point of view.

>
> I didn't review the patchset, but, from the description, I understood that
> it were developed to use some Dreambox-specific closed source applications.
> With such requirement, for me it is just a wrapper to some closed source
> application.

I understand that my English can be not crystal clear, so you missed
inside my description. But I must say it again - my code has zero
connection with dreamboxes. Of course other then borrowing theirs
sharing possibility and reusing same network daemons (again fully GPLed!)
for it.

>
> That's said, I'm not against a driver that allows using a DVB kernel
> driver by a DVB open source application either inside a virtual machine
> or on a remote machine. This seems useful for me. So, if the code could
> be turned into it, I'll review and consider for its inclusion upstream.

Then we should stop fighting and find some way for usual dialog.
My driver was born exactly wat that purpose - to virtualize remote
DVB adapter.

>
> For that to happen, it should not try to use any Dreambox specific application
> or protocol, but to just use the standard DVBv5 API, as you've pointed.

OK, If there is some change to not totally refuse such driver, then I will
be happy to refactor code this way.

/Honza

Re: [RFC] vtunerc - virtual DVB device driver

[Issa Gorissen]

I hope this driver will be included if it can be useful for some and if
it follows the GPL rules.

But really, +1 to Sebastien's comment - this project is a frustrating
one it seems. And at the point where I am, I would rather pay for a
working driver for a S2 + CI card, instead of trying to debug existing
drivers for which the maintainers are virtually non existent.

--
Issa

Re: [RFC] vtunerc - virtual DVB device driver

[Mauro Carvalho Chehab]

Em 21-06-2011 09:34, HoP escreveu:

>> For that to happen, it should not try to use any Dreambox specific application
>> or protocol, but to just use the standard DVBv5 API, as you've pointed.
> 
> OK, If there is some change to not totally refuse such driver, then I will
> be happy to refactor code this way.

Ok. Please address Andreas comments.

It is probably a good idea for you to take a look at the  Linux namespaces 
(search for LXC - Linux Containers), as it may be interesting to also add 
the possibility of using separate cgroups for either the client or the server 
side. The network stack is/were re-designed to use namespaces, but we didn't
make any changes at the media stack yet.

Some care should be taken at the protocol side, to avoid using something that
might be patented.

Cheers,
Mauro

Re: [RFC] vtunerc - virtual DVB device driver

[Devin Heitmueller]

On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
> Mauro and Devin, I think you're missing the point. This is not about
> creating drivers in userspace. This is not about open or closed source.
> The "vtuner" interface, as implemented for the Dreambox, is used to
> access remote tuners: Put x tuners into y boxes and access them from
> another box as if they were local. It's used in conjunction with further
> software to receive the transport stream over a network connection.
> Honza's code does the same thing.

I'm not missing the point at all.  I realize exactly what Honza is
trying to accomplish (and from a purely technical standpoint, it's not
a bad approach) - but I'm talking about the effects of such a driver
being introduced which changes the kernel/userland licensing boundary
and has very real implications with how the in-kernel code is
accessed.

> You don't need it in order to create closed source drivers. You can
> already create closed kernel drivers now. Also, you can create tuner
> drivers in userspace using the i2c-dev interface. If you like to connect
> a userspace driver to a DVB API device node, you can distribute a small
> (open or closed) wrapper with it. So what are you arguing about?
> Everything you're feared of can already be done since virtually forever.

I disagree.  There is currently no API which allows applications to
issue tuning requests into the DVB core, and have those requests
proxied back out to userland where an application can then use i2c-dev
to tune the actual device.  Meaning if somebody wants to write a
closed source userland application which controls the tuner, he/she
can do that (while not conforming to the DVB API).  But if if he wants
to reuse the GPL licensed DVB core, he has to replace the entire DVB
core.

The introduction of this patch makes it trivial for a third party to
provide closed-source userland support for tuners while reusing all
the existing GPL driver code that makes up the framework.

I used to work for a vendor that makes tuners, and they do a bunch of
Linux work.  And that work has resulted in a bunch of open source
drivers.  I can tell you though that *every* conversation I've had
regarding a new driver goes something like this:

===
"Devin, we need to support tuner X under Linux."

"Great!  I'll be happy to write a new GPL driver for the
tuner/demodulator/whatever for that device"

"But to save time/money, we just want to reuse the Windows driver code
(or reference code from the vendor)."

"Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"

"Not currently.  So can we just make our driver closed source?"

"Well, you can't reuse any of the existing DVB core functionality or
any of the other GPL drivers (tuners, bridges, demods), so you would
have rewrite all that from scratch."

"Oh, that would be a ton of work.   Can we maybe write some userland
stuff that controls the demodulator which we can keep closed source?
Since it's not in the kernel, the GPL won't apply".

"Well, you can't really do that because there is no way for the DVB
core to call back out to userland when the application makes the
tuning request to the DVB core."

"Oh, ok then.  I guess we'll have to talk to the vendor and get them
to give us the reference driver code under the GPL."
===

I can tell you without a doubt that if this driver were present in the
kernel, that going forward that vendor would have *zero* interest in
doing any GPL driver work.  Why would they?  Why give away the code
which could potentially help their competitors if they can keep it
safe and protected while still being able to reuse everybody else's
contributions?

Companies don't contribute GPL code out of "good will".  They do it
because they are compelled to by licenses or because there is no
economically viable alternative.

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.

Anyway, I said in my last email that would be my last email on the
topic.  I guess I lied.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: [RFC] vtunerc - virtual DVB device driver

[Andreas Oberritter]

On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
>> Mauro and Devin, I think you're missing the point. This is not about
>> creating drivers in userspace. This is not about open or closed source.
>> The "vtuner" interface, as implemented for the Dreambox, is used to
>> access remote tuners: Put x tuners into y boxes and access them from
>> another box as if they were local. It's used in conjunction with further
>> software to receive the transport stream over a network connection.
>> Honza's code does the same thing.
> 
> I'm not missing the point at all.  I realize exactly what Honza is
> trying to accomplish (and from a purely technical standpoint, it's not
> a bad approach) - but I'm talking about the effects of such a driver
> being introduced which changes the kernel/userland licensing boundary
> and has very real implications with how the in-kernel code is
> accessed.
> 
>> You don't need it in order to create closed source drivers. You can
>> already create closed kernel drivers now. Also, you can create tuner
>> drivers in userspace using the i2c-dev interface. If you like to connect
>> a userspace driver to a DVB API device node, you can distribute a small
>> (open or closed) wrapper with it. So what are you arguing about?
>> Everything you're feared of can already be done since virtually forever.
> 
> I disagree.  There is currently no API which allows applications to
> issue tuning requests into the DVB core, and have those requests
> proxied back out to userland where an application can then use i2c-dev
> to tune the actual device.  Meaning if somebody wants to write a
> closed source userland application which controls the tuner, he/she
> can do that (while not conforming to the DVB API).  But if if he wants
> to reuse the GPL licensed DVB core, he has to replace the entire DVB
> core.
> 
> The introduction of this patch makes it trivial for a third party to
> provide closed-source userland support for tuners while reusing all
> the existing GPL driver code that makes up the framework.
> 
> I used to work for a vendor that makes tuners, and they do a bunch of
> Linux work.  And that work has resulted in a bunch of open source
> drivers.  I can tell you though that *every* conversation I've had
> regarding a new driver goes something like this:
> 
> ===
> "Devin, we need to support tuner X under Linux."
> 
> "Great!  I'll be happy to write a new GPL driver for the
> tuner/demodulator/whatever for that device"
> 
> "But to save time/money, we just want to reuse the Windows driver code
> (or reference code from the vendor)."
> 
> "Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"
> 
> "Not currently.  So can we just make our driver closed source?"
> 
> "Well, you can't reuse any of the existing DVB core functionality or
> any of the other GPL drivers (tuners, bridges, demods), so you would
> have rewrite all that from scratch."
> 
> "Oh, that would be a ton of work.   Can we maybe write some userland
> stuff that controls the demodulator which we can keep closed source?
> Since it's not in the kernel, the GPL won't apply".
> 
> "Well, you can't really do that because there is no way for the DVB
> core to call back out to userland when the application makes the
> tuning request to the DVB core."
> 
> "Oh, ok then.  I guess we'll have to talk to the vendor and get them
> to give us the reference driver code under the GPL."
> ===
> 
> I can tell you without a doubt that if this driver were present in the
> kernel, that going forward that vendor would have *zero* interest in
> doing any GPL driver work.  Why would they?  Why give away the code
> which could potentially help their competitors if they can keep it
> safe and protected while still being able to reuse everybody else's
> contributions?
> 
> Companies don't contribute GPL code out of "good will".  They do it
> because they are compelled to by licenses or because there is no
> economically viable alternative.
> 
> 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.
> 
> Anyway, I said in my last email that would be my last email on the
> topic.  I guess I lied.

Yes, and you did lie to your vendor, too, as you did not mention the
possibilities to create
1.) closed source modules derived from existing vendor drivers while
still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
EXPORT_SYMBOL_GPL).
2.) a simple wrapper that calls userspace, therefore not having to open
up any "secrets" at all.

Of course it's nice that you could trick that vendor into publishing
code under GPL terms. And while everyone appreciates it, I would also
appreciate keeping politics off the table.

If the proposed interface results in closed userspace drivers, better or
worse than the kernel drivers, then so be it. It will be very easy to
log their I2C transactions and to create open source drivers from that.

Regards,
Andreas

Re: [RFC] vtunerc - virtual DVB device driver

[Devin Heitmueller]

2011/6/21 Andreas Oberritter <obi@linuxtv.org>:
> Yes, and you did lie to your vendor, too, as you did not mention the
> possibilities to create

I don't know if this is a language barrier issue, but calling someone
a liar (let alone in an open forum) is a pretty offensive thing to do.

In fact, such discussions did come up.  However I simply didn't
mention them here in the previous email in an attempt consolidate one
hour conversations into nine sentences in an attempt at brevity.

> 1.) closed source modules derived from existing vendor drivers while
> still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
> EXPORT_SYMBOL_GPL).

This definitely enters a grey area from a legal standpoint.  Depending
on who you talk to, using such symbols may or may not violate the GPL,
depending on what lawyer you talk to.  This all falls back to the
notion of whether non-GPL loadable modules violate the GPL, for which
even today there is considerable debate within the kernel community.

Smart companies are generally risk-averse, and recognize that it's
usually not worth the risk of being sued by doing something that may
or may not violate a license.

> 2.) a simple wrapper that calls userspace, therefore not having to open
> up any "secrets" at all.

Like the above, this raises all sorts of issues involving the
definition of "derivative work".

Again, we're going around in circles here.  This issue has been beaten
to death both in the linux dvb mailing lists as well as in the lkml in
general.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: [RFC] vtunerc - virtual DVB device driver

[Mauro Carvalho Chehab]

Em 21-06-2011 11:15, Andreas Oberritter escreveu:
> On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
>>> Mauro and Devin, I think you're missing the point. This is not about
>>> creating drivers in userspace. This is not about open or closed source.
>>> The "vtuner" interface, as implemented for the Dreambox, is used to
>>> access remote tuners: Put x tuners into y boxes and access them from
>>> another box as if they were local. It's used in conjunction with further
>>> software to receive the transport stream over a network connection.
>>> Honza's code does the same thing.
>>
>> I'm not missing the point at all.  I realize exactly what Honza is
>> trying to accomplish (and from a purely technical standpoint, it's not
>> a bad approach) - but I'm talking about the effects of such a driver
>> being introduced which changes the kernel/userland licensing boundary
>> and has very real implications with how the in-kernel code is
>> accessed.
>>
>>> You don't need it in order to create closed source drivers. You can
>>> already create closed kernel drivers now. Also, you can create tuner
>>> drivers in userspace using the i2c-dev interface. If you like to connect
>>> a userspace driver to a DVB API device node, you can distribute a small
>>> (open or closed) wrapper with it. So what are you arguing about?
>>> Everything you're feared of can already be done since virtually forever.
>>
>> I disagree.  There is currently no API which allows applications to
>> issue tuning requests into the DVB core, and have those requests
>> proxied back out to userland where an application can then use i2c-dev
>> to tune the actual device.  Meaning if somebody wants to write a
>> closed source userland application which controls the tuner, he/she
>> can do that (while not conforming to the DVB API).  But if if he wants
>> to reuse the GPL licensed DVB core, he has to replace the entire DVB
>> core.
>>
>> The introduction of this patch makes it trivial for a third party to
>> provide closed-source userland support for tuners while reusing all
>> the existing GPL driver code that makes up the framework.
>>
>> I used to work for a vendor that makes tuners, and they do a bunch of
>> Linux work.  And that work has resulted in a bunch of open source
>> drivers.  I can tell you though that *every* conversation I've had
>> regarding a new driver goes something like this:
>>
>> ===
>> "Devin, we need to support tuner X under Linux."
>>
>> "Great!  I'll be happy to write a new GPL driver for the
>> tuner/demodulator/whatever for that device"
>>
>> "But to save time/money, we just want to reuse the Windows driver code
>> (or reference code from the vendor)."
>>
>> "Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"
>>
>> "Not currently.  So can we just make our driver closed source?"
>>
>> "Well, you can't reuse any of the existing DVB core functionality or
>> any of the other GPL drivers (tuners, bridges, demods), so you would
>> have rewrite all that from scratch."
>>
>> "Oh, that would be a ton of work.   Can we maybe write some userland
>> stuff that controls the demodulator which we can keep closed source?
>> Since it's not in the kernel, the GPL won't apply".
>>
>> "Well, you can't really do that because there is no way for the DVB
>> core to call back out to userland when the application makes the
>> tuning request to the DVB core."
>>
>> "Oh, ok then.  I guess we'll have to talk to the vendor and get them
>> to give us the reference driver code under the GPL."
>> ===
>>
>> I can tell you without a doubt that if this driver were present in the
>> kernel, that going forward that vendor would have *zero* interest in
>> doing any GPL driver work.  Why would they?  Why give away the code
>> which could potentially help their competitors if they can keep it
>> safe and protected while still being able to reuse everybody else's
>> contributions?
>>
>> Companies don't contribute GPL code out of "good will".  They do it
>> because they are compelled to by licenses or because there is no
>> economically viable alternative.
>>
>> 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.
>>
>> Anyway, I said in my last email that would be my last email on the
>> topic.  I guess I lied.
> 
> Yes, and you did lie to your vendor, too, as you did not mention the
> possibilities to create
> 1.) closed source modules derived from existing vendor drivers while
> still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
> EXPORT_SYMBOL_GPL).

AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL
are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly 
adds a restriction, not using it doesn't necessarily mean that the symbol
can be used by a closed source driver. 

If you take a look at Kernel's COPYING file, the only exception to GPL license
allowed there is:

	 NOTE! This copyright does *not* cover user programs that use kernel
	 services by normal system calls - this is merely considered normal use
	 of the kernel, and does *not* fall under the heading of "derived work".

IANAL, but, as EXPORT_SYMBOL is not a "normal system call", my understanding is that
it is also covered by GPL.

I was told that several lawyers defend the idea that all software inside the
kernel tree is covered by GPL, even the aggregated ones. That was the rationale 
used to split the firmware packages from the kernel itself.

> 2.) a simple wrapper that calls userspace, therefore not having to open
> up any "secrets" at all.

A wrapper for a closed source driver is illegal, as it is trying to circumvent
the GPL license.

Mauro.

Re: [RFC] vtunerc - virtual DVB device driver

[Bjørn Mork]

Devin Heitmueller <dheitmueller@kernellabs.com> writes:

> The introduction of this patch makes it trivial for a third party to
> provide closed-source userland support for tuners while reusing all
> the existing GPL driver code that makes up the framework.

Wouldn't it be just as trivial to bundle the closed-source tuner support
with this patch or a similar GPL licensed driver? This doesn't change
anything wrt closed source drivers.


Bjørn

Re: [RFC] vtunerc - virtual DVB device driver

[Mauro Carvalho Chehab]

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

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

Re: [RFC] vtunerc - virtual DVB device driver

[Mauro Carvalho Chehab]

Em 21-06-2011 11:56, Bjørn Mork escreveu:
> Devin Heitmueller <dheitmueller@kernellabs.com> writes:
> 
>> The introduction of this patch makes it trivial for a third party to
>> provide closed-source userland support for tuners while reusing all
>> the existing GPL driver code that makes up the framework.
> 
> Wouldn't it be just as trivial to bundle the closed-source tuner support
> with this patch or a similar GPL licensed driver? This doesn't change
> anything wrt closed source drivers.

Yes, but adding some code into a GPL licensed code is derivative work,
The end result is also covered by GPL (not only the kernelspace, but also
the userspace counterpart). If some company is doing things like that
and not providing the entire driver under GPL, if going to court, the judge 
will likely consider this as an explicitly attempt to violate the legal 
property of someone's else's copyright.

Mauro

Re: [RFC] vtunerc - virtual DVB device driver

[Andreas Oberritter]

On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
> Em 21-06-2011 11:15, Andreas Oberritter escreveu:
>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
>>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
>>>> Mauro and Devin, I think you're missing the point. This is not about
>>>> creating drivers in userspace. This is not about open or closed source.
>>>> The "vtuner" interface, as implemented for the Dreambox, is used to
>>>> access remote tuners: Put x tuners into y boxes and access them from
>>>> another box as if they were local. It's used in conjunction with further
>>>> software to receive the transport stream over a network connection.
>>>> Honza's code does the same thing.
>>>
>>> I'm not missing the point at all.  I realize exactly what Honza is
>>> trying to accomplish (and from a purely technical standpoint, it's not
>>> a bad approach) - but I'm talking about the effects of such a driver
>>> being introduced which changes the kernel/userland licensing boundary
>>> and has very real implications with how the in-kernel code is
>>> accessed.
>>>
>>>> You don't need it in order to create closed source drivers. You can
>>>> already create closed kernel drivers now. Also, you can create tuner
>>>> drivers in userspace using the i2c-dev interface. If you like to connect
>>>> a userspace driver to a DVB API device node, you can distribute a small
>>>> (open or closed) wrapper with it. So what are you arguing about?
>>>> Everything you're feared of can already be done since virtually forever.
>>>
>>> I disagree.  There is currently no API which allows applications to
>>> issue tuning requests into the DVB core, and have those requests
>>> proxied back out to userland where an application can then use i2c-dev
>>> to tune the actual device.  Meaning if somebody wants to write a
>>> closed source userland application which controls the tuner, he/she
>>> can do that (while not conforming to the DVB API).  But if if he wants
>>> to reuse the GPL licensed DVB core, he has to replace the entire DVB
>>> core.
>>>
>>> The introduction of this patch makes it trivial for a third party to
>>> provide closed-source userland support for tuners while reusing all
>>> the existing GPL driver code that makes up the framework.
>>>
>>> I used to work for a vendor that makes tuners, and they do a bunch of
>>> Linux work.  And that work has resulted in a bunch of open source
>>> drivers.  I can tell you though that *every* conversation I've had
>>> regarding a new driver goes something like this:
>>>
>>> ===
>>> "Devin, we need to support tuner X under Linux."
>>>
>>> "Great!  I'll be happy to write a new GPL driver for the
>>> tuner/demodulator/whatever for that device"
>>>
>>> "But to save time/money, we just want to reuse the Windows driver code
>>> (or reference code from the vendor)."
>>>
>>> "Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"
>>>
>>> "Not currently.  So can we just make our driver closed source?"
>>>
>>> "Well, you can't reuse any of the existing DVB core functionality or
>>> any of the other GPL drivers (tuners, bridges, demods), so you would
>>> have rewrite all that from scratch."
>>>
>>> "Oh, that would be a ton of work.   Can we maybe write some userland
>>> stuff that controls the demodulator which we can keep closed source?
>>> Since it's not in the kernel, the GPL won't apply".
>>>
>>> "Well, you can't really do that because there is no way for the DVB
>>> core to call back out to userland when the application makes the
>>> tuning request to the DVB core."
>>>
>>> "Oh, ok then.  I guess we'll have to talk to the vendor and get them
>>> to give us the reference driver code under the GPL."
>>> ===
>>>
>>> I can tell you without a doubt that if this driver were present in the
>>> kernel, that going forward that vendor would have *zero* interest in
>>> doing any GPL driver work.  Why would they?  Why give away the code
>>> which could potentially help their competitors if they can keep it
>>> safe and protected while still being able to reuse everybody else's
>>> contributions?
>>>
>>> Companies don't contribute GPL code out of "good will".  They do it
>>> because they are compelled to by licenses or because there is no
>>> economically viable alternative.
>>>
>>> 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.
>>>
>>> Anyway, I said in my last email that would be my last email on the
>>> topic.  I guess I lied.
>>
>> Yes, and you did lie to your vendor, too, as you did not mention the
>> possibilities to create
>> 1.) closed source modules derived from existing vendor drivers while
>> still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
>> EXPORT_SYMBOL_GPL).
> 
> AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL
> are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly 
> adds a restriction, not using it doesn't necessarily mean that the symbol
> can be used by a closed source driver. 
> 
> If you take a look at Kernel's COPYING file, the only exception to GPL license
> allowed there is:
> 
> 	 NOTE! This copyright does *not* cover user programs that use kernel
> 	 services by normal system calls - this is merely considered normal use
> 	 of the kernel, and does *not* fall under the heading of "derived work".
> 
> IANAL, but, as EXPORT_SYMBOL is not a "normal system call", my understanding is that
> it is also covered by GPL.

Of course. But as you should know, the GPL only covers derived work.
Whether or not a driver is a derived work of the kernel can only be
decided individually. It is my understanding that a Windows driver
ported to Linux is unlikely to be a derived work of Linux.

> I was told that several lawyers defend the idea that all software inside the
> kernel tree is covered by GPL, even the aggregated ones. That was the rationale 
> used to split the firmware packages from the kernel itself.

However, I wasn't referring to the kernel tree at all.

>> 2.) a simple wrapper that calls userspace, therefore not having to open
>> up any "secrets" at all.
> 
> A wrapper for a closed source driver is illegal, as it is trying to circumvent
> the GPL license.

Is it? First, you are not a lawyer. Second, a wrapper is unlikely to be
illegal by its pure existence and a wrapper does usually not try to do
anything by itself. Third, you can implement a wrapper using normal
system calls (read, write, mmap, ioctl ...). That's what vtuner does,
too, to accomplish a totally different goal. Do you think vtuner is
illegal? I would be very surprised if it was. It perfectly matches the
license exception cited above. And even without the exception, a closed
driver in userspace would only very unlikely be a derived work of the
kernel.

Regards,
Andreas

Re: [RFC] vtunerc - virtual DVB device driver

[Mauro Carvalho Chehab]

Em 21-06-2011 12:09, Andreas Oberritter escreveu:
> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
>> Em 21-06-2011 11:15, Andreas Oberritter escreveu:
>>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
>>>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
>>>>> Mauro and Devin, I think you're missing the point. This is not about
>>>>> creating drivers in userspace. This is not about open or closed source.
>>>>> The "vtuner" interface, as implemented for the Dreambox, is used to
>>>>> access remote tuners: Put x tuners into y boxes and access them from
>>>>> another box as if they were local. It's used in conjunction with further
>>>>> software to receive the transport stream over a network connection.
>>>>> Honza's code does the same thing.
>>>>
>>>> I'm not missing the point at all.  I realize exactly what Honza is
>>>> trying to accomplish (and from a purely technical standpoint, it's not
>>>> a bad approach) - but I'm talking about the effects of such a driver
>>>> being introduced which changes the kernel/userland licensing boundary
>>>> and has very real implications with how the in-kernel code is
>>>> accessed.
>>>>
>>>>> You don't need it in order to create closed source drivers. You can
>>>>> already create closed kernel drivers now. Also, you can create tuner
>>>>> drivers in userspace using the i2c-dev interface. If you like to connect
>>>>> a userspace driver to a DVB API device node, you can distribute a small
>>>>> (open or closed) wrapper with it. So what are you arguing about?
>>>>> Everything you're feared of can already be done since virtually forever.
>>>>
>>>> I disagree.  There is currently no API which allows applications to
>>>> issue tuning requests into the DVB core, and have those requests
>>>> proxied back out to userland where an application can then use i2c-dev
>>>> to tune the actual device.  Meaning if somebody wants to write a
>>>> closed source userland application which controls the tuner, he/she
>>>> can do that (while not conforming to the DVB API).  But if if he wants
>>>> to reuse the GPL licensed DVB core, he has to replace the entire DVB
>>>> core.
>>>>
>>>> The introduction of this patch makes it trivial for a third party to
>>>> provide closed-source userland support for tuners while reusing all
>>>> the existing GPL driver code that makes up the framework.
>>>>
>>>> I used to work for a vendor that makes tuners, and they do a bunch of
>>>> Linux work.  And that work has resulted in a bunch of open source
>>>> drivers.  I can tell you though that *every* conversation I've had
>>>> regarding a new driver goes something like this:
>>>>
>>>> ===
>>>> "Devin, we need to support tuner X under Linux."
>>>>
>>>> "Great!  I'll be happy to write a new GPL driver for the
>>>> tuner/demodulator/whatever for that device"
>>>>
>>>> "But to save time/money, we just want to reuse the Windows driver code
>>>> (or reference code from the vendor)."
>>>>
>>>> "Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"
>>>>
>>>> "Not currently.  So can we just make our driver closed source?"
>>>>
>>>> "Well, you can't reuse any of the existing DVB core functionality or
>>>> any of the other GPL drivers (tuners, bridges, demods), so you would
>>>> have rewrite all that from scratch."
>>>>
>>>> "Oh, that would be a ton of work.   Can we maybe write some userland
>>>> stuff that controls the demodulator which we can keep closed source?
>>>> Since it's not in the kernel, the GPL won't apply".
>>>>
>>>> "Well, you can't really do that because there is no way for the DVB
>>>> core to call back out to userland when the application makes the
>>>> tuning request to the DVB core."
>>>>
>>>> "Oh, ok then.  I guess we'll have to talk to the vendor and get them
>>>> to give us the reference driver code under the GPL."
>>>> ===
>>>>
>>>> I can tell you without a doubt that if this driver were present in the
>>>> kernel, that going forward that vendor would have *zero* interest in
>>>> doing any GPL driver work.  Why would they?  Why give away the code
>>>> which could potentially help their competitors if they can keep it
>>>> safe and protected while still being able to reuse everybody else's
>>>> contributions?
>>>>
>>>> Companies don't contribute GPL code out of "good will".  They do it
>>>> because they are compelled to by licenses or because there is no
>>>> economically viable alternative.
>>>>
>>>> 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.
>>>>
>>>> Anyway, I said in my last email that would be my last email on the
>>>> topic.  I guess I lied.
>>>
>>> Yes, and you did lie to your vendor, too, as you did not mention the
>>> possibilities to create
>>> 1.) closed source modules derived from existing vendor drivers while
>>> still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
>>> EXPORT_SYMBOL_GPL).
>>
>> AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL
>> are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly 
>> adds a restriction, not using it doesn't necessarily mean that the symbol
>> can be used by a closed source driver. 
>>
>> If you take a look at Kernel's COPYING file, the only exception to GPL license
>> allowed there is:
>>
>> 	 NOTE! This copyright does *not* cover user programs that use kernel
>> 	 services by normal system calls - this is merely considered normal use
>> 	 of the kernel, and does *not* fall under the heading of "derived work".
>>
>> IANAL, but, as EXPORT_SYMBOL is not a "normal system call", my understanding is that
>> it is also covered by GPL.
> 
> Of course. But as you should know, the GPL only covers derived work.
> Whether or not a driver is a derived work of the kernel can only be
> decided individually. It is my understanding that a Windows driver
> ported to Linux is unlikely to be a derived work of Linux.
> 
>> I was told that several lawyers defend the idea that all software inside the
>> kernel tree is covered by GPL, even the aggregated ones. That was the rationale 
>> used to split the firmware packages from the kernel itself.
> 
> However, I wasn't referring to the kernel tree at all.
> 
>>> 2.) a simple wrapper that calls userspace, therefore not having to open
>>> up any "secrets" at all.
>>
>> A wrapper for a closed source driver is illegal, as it is trying to circumvent
>> the GPL license.
> 
> Is it? First, you are not a lawyer. Second, a wrapper is unlikely to be
> illegal by its pure existence and a wrapper does usually not try to do
> anything by itself. Third, you can implement a wrapper using normal
> system calls (read, write, mmap, ioctl ...). That's what vtuner does,
> too, to accomplish a totally different goal. Do you think vtuner is
> illegal? I would be very surprised if it was. It perfectly matches the
> license exception cited above. And even without the exception, a closed
> driver in userspace would only very unlikely be a derived work of the
> kernel.

I think we're diverging from the subject. Most of those discussions are 
interesting on some lawyers forum, not here.

My view about this subject is that vtuner can't give any additional permissions
to the kernel GPL'd code, as vtuner were not made by the Kernel Copyright owners,
nor were approved by them. So, the extra permission at the COPYING clause
from kernel doesn't apply here, while the code is not merged into the Kernel.

So, while it should be legal to use vtuner with a GPL'd client application,
using it by a closed source application violates GPL.

My understanding is that an addition of a code that exposes the internal
DVB core API to userspace like that will require that all dvb developers
that have copyright rights at the dvb core should explicitly ack with such
change, otherwise adding such code will violate the original license.

On the other hand, if vtunerc won't act as a proxy to userspace, it should 
probably be ok.

If people have different understandings, then we'll likely need to ask some
support from Open source lawyers about this subject.

Cheers,
Mauro

Re: [RFC] vtunerc - virtual DVB device driver

[Markus Rechberger]

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
>

Re: [RFC] vtunerc - virtual DVB device driver

[HoP]

2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
> Em 21-06-2011 12:09, Andreas Oberritter escreveu:
>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
>>> Em 21-06-2011 11:15, Andreas Oberritter escreveu:
>>>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
>>>>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
>>>>>> Mauro and Devin, I think you're missing the point. This is not about
>>>>>> creating drivers in userspace. This is not about open or closed source.
>>>>>> The "vtuner" interface, as implemented for the Dreambox, is used to
>>>>>> access remote tuners: Put x tuners into y boxes and access them from
>>>>>> another box as if they were local. It's used in conjunction with further
>>>>>> software to receive the transport stream over a network connection.
>>>>>> Honza's code does the same thing.
>>>>>
>>>>> I'm not missing the point at all.  I realize exactly what Honza is
>>>>> trying to accomplish (and from a purely technical standpoint, it's not
>>>>> a bad approach) - but I'm talking about the effects of such a driver
>>>>> being introduced which changes the kernel/userland licensing boundary
>>>>> and has very real implications with how the in-kernel code is
>>>>> accessed.
>>>>>
>>>>>> You don't need it in order to create closed source drivers. You can
>>>>>> already create closed kernel drivers now. Also, you can create tuner
>>>>>> drivers in userspace using the i2c-dev interface. If you like to connect
>>>>>> a userspace driver to a DVB API device node, you can distribute a small
>>>>>> (open or closed) wrapper with it. So what are you arguing about?
>>>>>> Everything you're feared of can already be done since virtually forever.
>>>>>
>>>>> I disagree.  There is currently no API which allows applications to
>>>>> issue tuning requests into the DVB core, and have those requests
>>>>> proxied back out to userland where an application can then use i2c-dev
>>>>> to tune the actual device.  Meaning if somebody wants to write a
>>>>> closed source userland application which controls the tuner, he/she
>>>>> can do that (while not conforming to the DVB API).  But if if he wants
>>>>> to reuse the GPL licensed DVB core, he has to replace the entire DVB
>>>>> core.
>>>>>
>>>>> The introduction of this patch makes it trivial for a third party to
>>>>> provide closed-source userland support for tuners while reusing all
>>>>> the existing GPL driver code that makes up the framework.
>>>>>
>>>>> I used to work for a vendor that makes tuners, and they do a bunch of
>>>>> Linux work.  And that work has resulted in a bunch of open source
>>>>> drivers.  I can tell you though that *every* conversation I've had
>>>>> regarding a new driver goes something like this:
>>>>>
>>>>> ===
>>>>> "Devin, we need to support tuner X under Linux."
>>>>>
>>>>> "Great!  I'll be happy to write a new GPL driver for the
>>>>> tuner/demodulator/whatever for that device"
>>>>>
>>>>> "But to save time/money, we just want to reuse the Windows driver code
>>>>> (or reference code from the vendor)."
>>>>>
>>>>> "Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"
>>>>>
>>>>> "Not currently.  So can we just make our driver closed source?"
>>>>>
>>>>> "Well, you can't reuse any of the existing DVB core functionality or
>>>>> any of the other GPL drivers (tuners, bridges, demods), so you would
>>>>> have rewrite all that from scratch."
>>>>>
>>>>> "Oh, that would be a ton of work.   Can we maybe write some userland
>>>>> stuff that controls the demodulator which we can keep closed source?
>>>>> Since it's not in the kernel, the GPL won't apply".
>>>>>
>>>>> "Well, you can't really do that because there is no way for the DVB
>>>>> core to call back out to userland when the application makes the
>>>>> tuning request to the DVB core."
>>>>>
>>>>> "Oh, ok then.  I guess we'll have to talk to the vendor and get them
>>>>> to give us the reference driver code under the GPL."
>>>>> ===
>>>>>
>>>>> I can tell you without a doubt that if this driver were present in the
>>>>> kernel, that going forward that vendor would have *zero* interest in
>>>>> doing any GPL driver work.  Why would they?  Why give away the code
>>>>> which could potentially help their competitors if they can keep it
>>>>> safe and protected while still being able to reuse everybody else's
>>>>> contributions?
>>>>>
>>>>> Companies don't contribute GPL code out of "good will".  They do it
>>>>> because they are compelled to by licenses or because there is no
>>>>> economically viable alternative.
>>>>>
>>>>> 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.
>>>>>
>>>>> Anyway, I said in my last email that would be my last email on the
>>>>> topic.  I guess I lied.
>>>>
>>>> Yes, and you did lie to your vendor, too, as you did not mention the
>>>> possibilities to create
>>>> 1.) closed source modules derived from existing vendor drivers while
>>>> still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
>>>> EXPORT_SYMBOL_GPL).
>>>
>>> AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL
>>> are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly
>>> adds a restriction, not using it doesn't necessarily mean that the symbol
>>> can be used by a closed source driver.
>>>
>>> If you take a look at Kernel's COPYING file, the only exception to GPL license
>>> allowed there is:
>>>
>>>       NOTE! This copyright does *not* cover user programs that use kernel
>>>       services by normal system calls - this is merely considered normal use
>>>       of the kernel, and does *not* fall under the heading of "derived work".
>>>
>>> IANAL, but, as EXPORT_SYMBOL is not a "normal system call", my understanding is that
>>> it is also covered by GPL.
>>
>> Of course. But as you should know, the GPL only covers derived work.
>> Whether or not a driver is a derived work of the kernel can only be
>> decided individually. It is my understanding that a Windows driver
>> ported to Linux is unlikely to be a derived work of Linux.
>>
>>> I was told that several lawyers defend the idea that all software inside the
>>> kernel tree is covered by GPL, even the aggregated ones. That was the rationale
>>> used to split the firmware packages from the kernel itself.
>>
>> However, I wasn't referring to the kernel tree at all.
>>
>>>> 2.) a simple wrapper that calls userspace, therefore not having to open
>>>> up any "secrets" at all.
>>>
>>> A wrapper for a closed source driver is illegal, as it is trying to circumvent
>>> the GPL license.
>>
>> Is it? First, you are not a lawyer. Second, a wrapper is unlikely to be
>> illegal by its pure existence and a wrapper does usually not try to do
>> anything by itself. Third, you can implement a wrapper using normal
>> system calls (read, write, mmap, ioctl ...). That's what vtuner does,
>> too, to accomplish a totally different goal. Do you think vtuner is
>> illegal? I would be very surprised if it was. It perfectly matches the
>> license exception cited above. And even without the exception, a closed
>> driver in userspace would only very unlikely be a derived work of the
>> kernel.
>
> I think we're diverging from the subject. Most of those discussions are
> interesting on some lawyers forum, not here.
>
> My view about this subject is that vtuner can't give any additional permissions
> to the kernel GPL'd code, as vtuner were not made by the Kernel Copyright owners,
> nor were approved by them. So, the extra permission at the COPYING clause
> from kernel doesn't apply here, while the code is not merged into the Kernel.
>
> So, while it should be legal to use vtuner with a GPL'd client application,
> using it by a closed source application violates GPL.
>
> My understanding is that an addition of a code that exposes the internal
> DVB core API to userspace like that will require that all dvb developers
> that have copyright rights at the dvb core should explicitly ack with such
> change, otherwise adding such code will violate the original license.
>
> On the other hand, if vtunerc won't act as a proxy to userspace, it should
> probably be ok.

Are you serious? Why there is not same violation on NFS? Or even beter
example NBD (network block device)? It sits in kernel for ages and nobody
cares. It looks for me like you should send some patch for removal such
"weak" places in kernel which allow to violate GPL.

Do you really think that it is possible (in real, no in threory) to create
any networked subsystem for sharing anything over net the way
when it is not exposed (somehow) to the userspace? How will be
such system managable? Why there is usually companion daemon
there, which is responsible for managing connections etc?

I think it is very evident you want find the way how to get yours word
back and return to your original position = such code is not acceptable.
Even if you still are not able to give anything clear.

If I understand your last few mails, you won't accept such driver, isn't it?

>
> If people have different understandings, then we'll likely need to ask some
> support from Open source lawyers about this subject.

My very little opinion is that waving GPL is way to the hell. Nobody told me
why similar technologies, in different kernel parts are acceptable,
but not here.

/Honza

Re: [RFC] vtunerc - virtual DVB device driver

[Markus Rechberger]

>
> My very little opinion is that waving GPL is way to the hell. Nobody told me
> why similar technologies, in different kernel parts are acceptable,
> but not here.
>

since a customer was trying to use this module the only feedback I can give
right now is that there are still some fundamental bugs in that work.
Just running it with some intuitive parameters (without having a dvb
device connected) caused
it to hang.

./vtunerc.i686  -c 1
vtunerc: [5210 ../../vtunerc.c:349] debug: added frontend mode DVB-C
as mode 0, searching for tuner types 2
vtunerc: [5210 ../../vtunerc.c:346] error: unknown tuner mode
specified: 1 allow values are: -s -S -s2 -S2 -c -t
it just never returned.

DMESG:
vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer
vtunerc: [5207 ../../vtunerc.c:606] info: msg: 4096 completed
vtunerc: [5207 ../../vtunerc.c:506] info: vtuner message!
vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer

ps fax | grep vtunerc:
 5194 pts/4    S      0:00  |       \_ bash
 5210 pts/4    S+     0:00  |           \_ [vtunerc.i686]

that way it's not good enough for inclusion yet anyway.

Markus

Re: [RFC] vtunerc - virtual DVB device driver

[HoP]

2011/6/22 Markus Rechberger <mrechberger@gmail.com>:
>>
>> My very little opinion is that waving GPL is way to the hell. Nobody told me
>> why similar technologies, in different kernel parts are acceptable,
>> but not here.
>>
>
> since a customer was trying to use this module the only feedback I can give
> right now is that there are still some fundamental bugs in that work.
> Just running it with some intuitive parameters (without having a dvb
> device connected) caused
> it to hang.
>
> ./vtunerc.i686  -c 1
> vtunerc: [5210 ../../vtunerc.c:349] debug: added frontend mode DVB-C
> as mode 0, searching for tuner types 2
> vtunerc: [5210 ../../vtunerc.c:346] error: unknown tuner mode
> specified: 1 allow values are: -s -S -s2 -S2 -c -t
> it just never returned.
>

Never returned? How it is possible if just next line is exit(1) call?

> DMESG:
> vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer
> vtunerc: [5207 ../../vtunerc.c:606] info: msg: 4096 completed
> vtunerc: [5207 ../../vtunerc.c:506] info: vtuner message!
> vtunerc: [5207 ../../vtunerc.c:593] info: fake server answer
>
> ps fax | grep vtunerc:
>  5194 pts/4    S      0:00  |       \_ bash
>  5210 pts/4    S+     0:00  |           \_ [vtunerc.i686]
>
> that way it's not good enough for inclusion yet anyway.

I never wanted to get it include immediatelly. I never stated that.
That is why subject of this mail starts with [RFC]. I wanted
to know if such driver is even interesting by others and if
so to get help from community having the code better.
I was already noted that it is my first kernel driver and I understand
that reviewing code by kernel hackers can help making
code better.

On the other hand I never thought that the code can be
totally refused because of its nature. Even I all time
was writing that all subsystem (kernel + userland daemons)
are GPL.

Marcus, tell the customer I'm just starting some howto
document to guide all willing to test how it works through
compilation and installation process.

In parallel I'm going to address all hints gave me by Andreas,
the only guy who even had a look at source.

Anyway, I'm happy for any feedback, so thanks.

/Honza

Re: [RFC] vtunerc - virtual DVB device driver

[Mauro Carvalho Chehab]

Em 21-06-2011 14:38, HoP escreveu:
> 2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
>> Em 21-06-2011 12:09, Andreas Oberritter escreveu:
>>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
>>>> Em 21-06-2011 11:15, Andreas Oberritter escreveu:
>>>>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
>>>>>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
>>>>>>> Mauro and Devin, I think you're missing the point. This is not about
>>>>>>> creating drivers in userspace. This is not about open or closed source.
>>>>>>> The "vtuner" interface, as implemented for the Dreambox, is used to
>>>>>>> access remote tuners: Put x tuners into y boxes and access them from
>>>>>>> another box as if they were local. It's used in conjunction with further
>>>>>>> software to receive the transport stream over a network connection.
>>>>>>> Honza's code does the same thing.
>>>>>>
>>>>>> I'm not missing the point at all.  I realize exactly what Honza is
>>>>>> trying to accomplish (and from a purely technical standpoint, it's not
>>>>>> a bad approach) - but I'm talking about the effects of such a driver
>>>>>> being introduced which changes the kernel/userland licensing boundary
>>>>>> and has very real implications with how the in-kernel code is
>>>>>> accessed.
>>>>>>
>>>>>>> You don't need it in order to create closed source drivers. You can
>>>>>>> already create closed kernel drivers now. Also, you can create tuner
>>>>>>> drivers in userspace using the i2c-dev interface. If you like to connect
>>>>>>> a userspace driver to a DVB API device node, you can distribute a small
>>>>>>> (open or closed) wrapper with it. So what are you arguing about?
>>>>>>> Everything you're feared of can already be done since virtually forever.
>>>>>>
>>>>>> I disagree.  There is currently no API which allows applications to
>>>>>> issue tuning requests into the DVB core, and have those requests
>>>>>> proxied back out to userland where an application can then use i2c-dev
>>>>>> to tune the actual device.  Meaning if somebody wants to write a
>>>>>> closed source userland application which controls the tuner, he/she
>>>>>> can do that (while not conforming to the DVB API).  But if if he wants
>>>>>> to reuse the GPL licensed DVB core, he has to replace the entire DVB
>>>>>> core.
>>>>>>
>>>>>> The introduction of this patch makes it trivial for a third party to
>>>>>> provide closed-source userland support for tuners while reusing all
>>>>>> the existing GPL driver code that makes up the framework.
>>>>>>
>>>>>> I used to work for a vendor that makes tuners, and they do a bunch of
>>>>>> Linux work.  And that work has resulted in a bunch of open source
>>>>>> drivers.  I can tell you though that *every* conversation I've had
>>>>>> regarding a new driver goes something like this:
>>>>>>
>>>>>> ===
>>>>>> "Devin, we need to support tuner X under Linux."
>>>>>>
>>>>>> "Great!  I'll be happy to write a new GPL driver for the
>>>>>> tuner/demodulator/whatever for that device"
>>>>>>
>>>>>> "But to save time/money, we just want to reuse the Windows driver code
>>>>>> (or reference code from the vendor)."
>>>>>>
>>>>>> "Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"
>>>>>>
>>>>>> "Not currently.  So can we just make our driver closed source?"
>>>>>>
>>>>>> "Well, you can't reuse any of the existing DVB core functionality or
>>>>>> any of the other GPL drivers (tuners, bridges, demods), so you would
>>>>>> have rewrite all that from scratch."
>>>>>>
>>>>>> "Oh, that would be a ton of work.   Can we maybe write some userland
>>>>>> stuff that controls the demodulator which we can keep closed source?
>>>>>> Since it's not in the kernel, the GPL won't apply".
>>>>>>
>>>>>> "Well, you can't really do that because there is no way for the DVB
>>>>>> core to call back out to userland when the application makes the
>>>>>> tuning request to the DVB core."
>>>>>>
>>>>>> "Oh, ok then.  I guess we'll have to talk to the vendor and get them
>>>>>> to give us the reference driver code under the GPL."
>>>>>> ===
>>>>>>
>>>>>> I can tell you without a doubt that if this driver were present in the
>>>>>> kernel, that going forward that vendor would have *zero* interest in
>>>>>> doing any GPL driver work.  Why would they?  Why give away the code
>>>>>> which could potentially help their competitors if they can keep it
>>>>>> safe and protected while still being able to reuse everybody else's
>>>>>> contributions?
>>>>>>
>>>>>> Companies don't contribute GPL code out of "good will".  They do it
>>>>>> because they are compelled to by licenses or because there is no
>>>>>> economically viable alternative.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Anyway, I said in my last email that would be my last email on the
>>>>>> topic.  I guess I lied.
>>>>>
>>>>> Yes, and you did lie to your vendor, too, as you did not mention the
>>>>> possibilities to create
>>>>> 1.) closed source modules derived from existing vendor drivers while
>>>>> still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
>>>>> EXPORT_SYMBOL_GPL).
>>>>
>>>> AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL
>>>> are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly
>>>> adds a restriction, not using it doesn't necessarily mean that the symbol
>>>> can be used by a closed source driver.
>>>>
>>>> If you take a look at Kernel's COPYING file, the only exception to GPL license
>>>> allowed there is:
>>>>
>>>>       NOTE! This copyright does *not* cover user programs that use kernel
>>>>       services by normal system calls - this is merely considered normal use
>>>>       of the kernel, and does *not* fall under the heading of "derived work".
>>>>
>>>> IANAL, but, as EXPORT_SYMBOL is not a "normal system call", my understanding is that
>>>> it is also covered by GPL.
>>>
>>> Of course. But as you should know, the GPL only covers derived work.
>>> Whether or not a driver is a derived work of the kernel can only be
>>> decided individually. It is my understanding that a Windows driver
>>> ported to Linux is unlikely to be a derived work of Linux.
>>>
>>>> I was told that several lawyers defend the idea that all software inside the
>>>> kernel tree is covered by GPL, even the aggregated ones. That was the rationale
>>>> used to split the firmware packages from the kernel itself.
>>>
>>> However, I wasn't referring to the kernel tree at all.
>>>
>>>>> 2.) a simple wrapper that calls userspace, therefore not having to open
>>>>> up any "secrets" at all.
>>>>
>>>> A wrapper for a closed source driver is illegal, as it is trying to circumvent
>>>> the GPL license.
>>>
>>> Is it? First, you are not a lawyer. Second, a wrapper is unlikely to be
>>> illegal by its pure existence and a wrapper does usually not try to do
>>> anything by itself. Third, you can implement a wrapper using normal
>>> system calls (read, write, mmap, ioctl ...). That's what vtuner does,
>>> too, to accomplish a totally different goal. Do you think vtuner is
>>> illegal? I would be very surprised if it was. It perfectly matches the
>>> license exception cited above. And even without the exception, a closed
>>> driver in userspace would only very unlikely be a derived work of the
>>> kernel.
>>
>> I think we're diverging from the subject. Most of those discussions are
>> interesting on some lawyers forum, not here.
>>
>> My view about this subject is that vtuner can't give any additional permissions
>> to the kernel GPL'd code, as vtuner were not made by the Kernel Copyright owners,
>> nor were approved by them. So, the extra permission at the COPYING clause
>> from kernel doesn't apply here, while the code is not merged into the Kernel.
>>
>> So, while it should be legal to use vtuner with a GPL'd client application,
>> using it by a closed source application violates GPL.
>>
>> My understanding is that an addition of a code that exposes the internal
>> DVB core API to userspace like that will require that all dvb developers
>> that have copyright rights at the dvb core should explicitly ack with such
>> change, otherwise adding such code will violate the original license.
>>
>> On the other hand, if vtunerc won't act as a proxy to userspace, it should
>> probably be ok.
> 
> Are you serious? Why there is not same violation on NFS? Or even beter
> example NBD (network block device)? It sits in kernel for ages and nobody
> cares. It looks for me like you should send some patch for removal such
> "weak" places in kernel which allow to violate GPL.
> 
> Do you really think that it is possible (in real, no in threory) to create
> any networked subsystem for sharing anything over net the way
> when it is not exposed (somehow) to the userspace? How will be
> such system managable? Why there is usually companion daemon
> there, which is responsible for managing connections etc?
> 
> I think it is very evident you want find the way how to get yours word
> back and return to your original position = such code is not acceptable.
> Even if you still are not able to give anything clear.
> 
> If I understand your last few mails, you won't accept such driver, isn't it?

You got wrong. You can't change someone's else license without their acks.
It is as simple as that. Getting everybody's ack is not that hard, if they
accept that what you're doing is the right thing. We've got everybody's
ack in the past to change the licensing for videodev2.h for example, to allow
using the V4L2 API under BSD license (just the license API was changed, not the
code itself).

>> If people have different understandings, then we'll likely need to ask some
>> support from Open source lawyers about this subject.
> 
> My very little opinion is that waving GPL is way to the hell. Nobody told me
> why similar technologies, in different kernel parts are acceptable,
> but not here.

If you want to do the networking code at userspace, why do you need a kernel
driver after all? The proper solution is to write an userspace library for that,
and either enclose such library inside the applications, or use LD_PRELOAD to
bind the library to handle the open/close/ioctl glibc calls. libv4l does that.
As it proofed to be a good library, now almost all V4L applications are using
it.

Mauro.

Re: [RFC] vtunerc - virtual DVB device driver

[Andreas Oberritter]

On 06/22/2011 02:17 PM, Mauro Carvalho Chehab wrote:
> Em 21-06-2011 14:38, HoP escreveu:
>> 2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>> Em 21-06-2011 12:09, Andreas Oberritter escreveu:
>>>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
>>>>> Em 21-06-2011 11:15, Andreas Oberritter escreveu:
>>>>>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
>>>>>>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
>>>>>>>> Mauro and Devin, I think you're missing the point. This is not about
>>>>>>>> creating drivers in userspace. This is not about open or closed source.
>>>>>>>> The "vtuner" interface, as implemented for the Dreambox, is used to
>>>>>>>> access remote tuners: Put x tuners into y boxes and access them from
>>>>>>>> another box as if they were local. It's used in conjunction with further
>>>>>>>> software to receive the transport stream over a network connection.
>>>>>>>> Honza's code does the same thing.
>>>>>>>
>>>>>>> I'm not missing the point at all.  I realize exactly what Honza is
>>>>>>> trying to accomplish (and from a purely technical standpoint, it's not
>>>>>>> a bad approach) - but I'm talking about the effects of such a driver
>>>>>>> being introduced which changes the kernel/userland licensing boundary
>>>>>>> and has very real implications with how the in-kernel code is
>>>>>>> accessed.
>>>>>>>
>>>>>>>> You don't need it in order to create closed source drivers. You can
>>>>>>>> already create closed kernel drivers now. Also, you can create tuner
>>>>>>>> drivers in userspace using the i2c-dev interface. If you like to connect
>>>>>>>> a userspace driver to a DVB API device node, you can distribute a small
>>>>>>>> (open or closed) wrapper with it. So what are you arguing about?
>>>>>>>> Everything you're feared of can already be done since virtually forever.
>>>>>>>
>>>>>>> I disagree.  There is currently no API which allows applications to
>>>>>>> issue tuning requests into the DVB core, and have those requests
>>>>>>> proxied back out to userland where an application can then use i2c-dev
>>>>>>> to tune the actual device.  Meaning if somebody wants to write a
>>>>>>> closed source userland application which controls the tuner, he/she
>>>>>>> can do that (while not conforming to the DVB API).  But if if he wants
>>>>>>> to reuse the GPL licensed DVB core, he has to replace the entire DVB
>>>>>>> core.
>>>>>>>
>>>>>>> The introduction of this patch makes it trivial for a third party to
>>>>>>> provide closed-source userland support for tuners while reusing all
>>>>>>> the existing GPL driver code that makes up the framework.
>>>>>>>
>>>>>>> I used to work for a vendor that makes tuners, and they do a bunch of
>>>>>>> Linux work.  And that work has resulted in a bunch of open source
>>>>>>> drivers.  I can tell you though that *every* conversation I've had
>>>>>>> regarding a new driver goes something like this:
>>>>>>>
>>>>>>> ===
>>>>>>> "Devin, we need to support tuner X under Linux."
>>>>>>>
>>>>>>> "Great!  I'll be happy to write a new GPL driver for the
>>>>>>> tuner/demodulator/whatever for that device"
>>>>>>>
>>>>>>> "But to save time/money, we just want to reuse the Windows driver code
>>>>>>> (or reference code from the vendor)."
>>>>>>>
>>>>>>> "Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"
>>>>>>>
>>>>>>> "Not currently.  So can we just make our driver closed source?"
>>>>>>>
>>>>>>> "Well, you can't reuse any of the existing DVB core functionality or
>>>>>>> any of the other GPL drivers (tuners, bridges, demods), so you would
>>>>>>> have rewrite all that from scratch."
>>>>>>>
>>>>>>> "Oh, that would be a ton of work.   Can we maybe write some userland
>>>>>>> stuff that controls the demodulator which we can keep closed source?
>>>>>>> Since it's not in the kernel, the GPL won't apply".
>>>>>>>
>>>>>>> "Well, you can't really do that because there is no way for the DVB
>>>>>>> core to call back out to userland when the application makes the
>>>>>>> tuning request to the DVB core."
>>>>>>>
>>>>>>> "Oh, ok then.  I guess we'll have to talk to the vendor and get them
>>>>>>> to give us the reference driver code under the GPL."
>>>>>>> ===
>>>>>>>
>>>>>>> I can tell you without a doubt that if this driver were present in the
>>>>>>> kernel, that going forward that vendor would have *zero* interest in
>>>>>>> doing any GPL driver work.  Why would they?  Why give away the code
>>>>>>> which could potentially help their competitors if they can keep it
>>>>>>> safe and protected while still being able to reuse everybody else's
>>>>>>> contributions?
>>>>>>>
>>>>>>> Companies don't contribute GPL code out of "good will".  They do it
>>>>>>> because they are compelled to by licenses or because there is no
>>>>>>> economically viable alternative.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> Anyway, I said in my last email that would be my last email on the
>>>>>>> topic.  I guess I lied.
>>>>>>
>>>>>> Yes, and you did lie to your vendor, too, as you did not mention the
>>>>>> possibilities to create
>>>>>> 1.) closed source modules derived from existing vendor drivers while
>>>>>> still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
>>>>>> EXPORT_SYMBOL_GPL).
>>>>>
>>>>> AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL
>>>>> are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly
>>>>> adds a restriction, not using it doesn't necessarily mean that the symbol
>>>>> can be used by a closed source driver.
>>>>>
>>>>> If you take a look at Kernel's COPYING file, the only exception to GPL license
>>>>> allowed there is:
>>>>>
>>>>>       NOTE! This copyright does *not* cover user programs that use kernel
>>>>>       services by normal system calls - this is merely considered normal use
>>>>>       of the kernel, and does *not* fall under the heading of "derived work".
>>>>>
>>>>> IANAL, but, as EXPORT_SYMBOL is not a "normal system call", my understanding is that
>>>>> it is also covered by GPL.
>>>>
>>>> Of course. But as you should know, the GPL only covers derived work.
>>>> Whether or not a driver is a derived work of the kernel can only be
>>>> decided individually. It is my understanding that a Windows driver
>>>> ported to Linux is unlikely to be a derived work of Linux.
>>>>
>>>>> I was told that several lawyers defend the idea that all software inside the
>>>>> kernel tree is covered by GPL, even the aggregated ones. That was the rationale
>>>>> used to split the firmware packages from the kernel itself.
>>>>
>>>> However, I wasn't referring to the kernel tree at all.
>>>>
>>>>>> 2.) a simple wrapper that calls userspace, therefore not having to open
>>>>>> up any "secrets" at all.
>>>>>
>>>>> A wrapper for a closed source driver is illegal, as it is trying to circumvent
>>>>> the GPL license.
>>>>
>>>> Is it? First, you are not a lawyer. Second, a wrapper is unlikely to be
>>>> illegal by its pure existence and a wrapper does usually not try to do
>>>> anything by itself. Third, you can implement a wrapper using normal
>>>> system calls (read, write, mmap, ioctl ...). That's what vtuner does,
>>>> too, to accomplish a totally different goal. Do you think vtuner is
>>>> illegal? I would be very surprised if it was. It perfectly matches the
>>>> license exception cited above. And even without the exception, a closed
>>>> driver in userspace would only very unlikely be a derived work of the
>>>> kernel.
>>>
>>> I think we're diverging from the subject. Most of those discussions are
>>> interesting on some lawyers forum, not here.
>>>
>>> My view about this subject is that vtuner can't give any additional permissions
>>> to the kernel GPL'd code, as vtuner were not made by the Kernel Copyright owners,
>>> nor were approved by them. So, the extra permission at the COPYING clause
>>> from kernel doesn't apply here, while the code is not merged into the Kernel.
>>>
>>> So, while it should be legal to use vtuner with a GPL'd client application,
>>> using it by a closed source application violates GPL.
>>>
>>> My understanding is that an addition of a code that exposes the internal
>>> DVB core API to userspace like that will require that all dvb developers
>>> that have copyright rights at the dvb core should explicitly ack with such
>>> change, otherwise adding such code will violate the original license.
>>>
>>> On the other hand, if vtunerc won't act as a proxy to userspace, it should
>>> probably be ok.
>>
>> Are you serious? Why there is not same violation on NFS? Or even beter
>> example NBD (network block device)? It sits in kernel for ages and nobody
>> cares. It looks for me like you should send some patch for removal such
>> "weak" places in kernel which allow to violate GPL.
>>
>> Do you really think that it is possible (in real, no in threory) to create
>> any networked subsystem for sharing anything over net the way
>> when it is not exposed (somehow) to the userspace? How will be
>> such system managable? Why there is usually companion daemon
>> there, which is responsible for managing connections etc?
>>
>> I think it is very evident you want find the way how to get yours word
>> back and return to your original position = such code is not acceptable.
>> Even if you still are not able to give anything clear.
>>
>> If I understand your last few mails, you won't accept such driver, isn't it?
> 
> You got wrong. You can't change someone's else license without their acks.
> It is as simple as that. Getting everybody's ack is not that hard, if they
> accept that what you're doing is the right thing. We've got everybody's
> ack in the past to change the licensing for videodev2.h for example, to allow
> using the V4L2 API under BSD license (just the license API was changed, not the
> code itself).

Is there anybode else who thinks that adding GPL'd code to the GPL'd
kernel would require any change in licensing? This is insane. What
change to whose license are you referring to, please?

Regards,
Andreas

Re: [RFC] vtunerc - virtual DVB device driver

[HoP]

2011/6/22 Mauro Carvalho Chehab <mchehab@redhat.com>:
> Em 21-06-2011 14:38, HoP escreveu:
>> 2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>> Em 21-06-2011 12:09, Andreas Oberritter escreveu:
>>>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
>>>>> Em 21-06-2011 11:15, Andreas Oberritter escreveu:
>>>>>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
>>>>>>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
>>>>>>>> Mauro and Devin, I think you're missing the point. This is not about
>>>>>>>> creating drivers in userspace. This is not about open or closed source.
>>>>>>>> The "vtuner" interface, as implemented for the Dreambox, is used to
>>>>>>>> access remote tuners: Put x tuners into y boxes and access them from
>>>>>>>> another box as if they were local. It's used in conjunction with further
>>>>>>>> software to receive the transport stream over a network connection.
>>>>>>>> Honza's code does the same thing.
>>>>>>>
>>>>>>> I'm not missing the point at all.  I realize exactly what Honza is
>>>>>>> trying to accomplish (and from a purely technical standpoint, it's not
>>>>>>> a bad approach) - but I'm talking about the effects of such a driver
>>>>>>> being introduced which changes the kernel/userland licensing boundary
>>>>>>> and has very real implications with how the in-kernel code is
>>>>>>> accessed.
>>>>>>>
>>>>>>>> You don't need it in order to create closed source drivers. You can
>>>>>>>> already create closed kernel drivers now. Also, you can create tuner
>>>>>>>> drivers in userspace using the i2c-dev interface. If you like to connect
>>>>>>>> a userspace driver to a DVB API device node, you can distribute a small
>>>>>>>> (open or closed) wrapper with it. So what are you arguing about?
>>>>>>>> Everything you're feared of can already be done since virtually forever.
>>>>>>>
>>>>>>> I disagree.  There is currently no API which allows applications to
>>>>>>> issue tuning requests into the DVB core, and have those requests
>>>>>>> proxied back out to userland where an application can then use i2c-dev
>>>>>>> to tune the actual device.  Meaning if somebody wants to write a
>>>>>>> closed source userland application which controls the tuner, he/she
>>>>>>> can do that (while not conforming to the DVB API).  But if if he wants
>>>>>>> to reuse the GPL licensed DVB core, he has to replace the entire DVB
>>>>>>> core.
>>>>>>>
>>>>>>> The introduction of this patch makes it trivial for a third party to
>>>>>>> provide closed-source userland support for tuners while reusing all
>>>>>>> the existing GPL driver code that makes up the framework.
>>>>>>>
>>>>>>> I used to work for a vendor that makes tuners, and they do a bunch of
>>>>>>> Linux work.  And that work has resulted in a bunch of open source
>>>>>>> drivers.  I can tell you though that *every* conversation I've had
>>>>>>> regarding a new driver goes something like this:
>>>>>>>
>>>>>>> ===
>>>>>>> "Devin, we need to support tuner X under Linux."
>>>>>>>
>>>>>>> "Great!  I'll be happy to write a new GPL driver for the
>>>>>>> tuner/demodulator/whatever for that device"
>>>>>>>
>>>>>>> "But to save time/money, we just want to reuse the Windows driver code
>>>>>>> (or reference code from the vendor)."
>>>>>>>
>>>>>>> "Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"
>>>>>>>
>>>>>>> "Not currently.  So can we just make our driver closed source?"
>>>>>>>
>>>>>>> "Well, you can't reuse any of the existing DVB core functionality or
>>>>>>> any of the other GPL drivers (tuners, bridges, demods), so you would
>>>>>>> have rewrite all that from scratch."
>>>>>>>
>>>>>>> "Oh, that would be a ton of work.   Can we maybe write some userland
>>>>>>> stuff that controls the demodulator which we can keep closed source?
>>>>>>> Since it's not in the kernel, the GPL won't apply".
>>>>>>>
>>>>>>> "Well, you can't really do that because there is no way for the DVB
>>>>>>> core to call back out to userland when the application makes the
>>>>>>> tuning request to the DVB core."
>>>>>>>
>>>>>>> "Oh, ok then.  I guess we'll have to talk to the vendor and get them
>>>>>>> to give us the reference driver code under the GPL."
>>>>>>> ===
>>>>>>>
>>>>>>> I can tell you without a doubt that if this driver were present in the
>>>>>>> kernel, that going forward that vendor would have *zero* interest in
>>>>>>> doing any GPL driver work.  Why would they?  Why give away the code
>>>>>>> which could potentially help their competitors if they can keep it
>>>>>>> safe and protected while still being able to reuse everybody else's
>>>>>>> contributions?
>>>>>>>
>>>>>>> Companies don't contribute GPL code out of "good will".  They do it
>>>>>>> because they are compelled to by licenses or because there is no
>>>>>>> economically viable alternative.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> Anyway, I said in my last email that would be my last email on the
>>>>>>> topic.  I guess I lied.
>>>>>>
>>>>>> Yes, and you did lie to your vendor, too, as you did not mention the
>>>>>> possibilities to create
>>>>>> 1.) closed source modules derived from existing vendor drivers while
>>>>>> still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
>>>>>> EXPORT_SYMBOL_GPL).
>>>>>
>>>>> AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL
>>>>> are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly
>>>>> adds a restriction, not using it doesn't necessarily mean that the symbol
>>>>> can be used by a closed source driver.
>>>>>
>>>>> If you take a look at Kernel's COPYING file, the only exception to GPL license
>>>>> allowed there is:
>>>>>
>>>>>       NOTE! This copyright does *not* cover user programs that use kernel
>>>>>       services by normal system calls - this is merely considered normal use
>>>>>       of the kernel, and does *not* fall under the heading of "derived work".
>>>>>
>>>>> IANAL, but, as EXPORT_SYMBOL is not a "normal system call", my understanding is that
>>>>> it is also covered by GPL.
>>>>
>>>> Of course. But as you should know, the GPL only covers derived work.
>>>> Whether or not a driver is a derived work of the kernel can only be
>>>> decided individually. It is my understanding that a Windows driver
>>>> ported to Linux is unlikely to be a derived work of Linux.
>>>>
>>>>> I was told that several lawyers defend the idea that all software inside the
>>>>> kernel tree is covered by GPL, even the aggregated ones. That was the rationale
>>>>> used to split the firmware packages from the kernel itself.
>>>>
>>>> However, I wasn't referring to the kernel tree at all.
>>>>
>>>>>> 2.) a simple wrapper that calls userspace, therefore not having to open
>>>>>> up any "secrets" at all.
>>>>>
>>>>> A wrapper for a closed source driver is illegal, as it is trying to circumvent
>>>>> the GPL license.
>>>>
>>>> Is it? First, you are not a lawyer. Second, a wrapper is unlikely to be
>>>> illegal by its pure existence and a wrapper does usually not try to do
>>>> anything by itself. Third, you can implement a wrapper using normal
>>>> system calls (read, write, mmap, ioctl ...). That's what vtuner does,
>>>> too, to accomplish a totally different goal. Do you think vtuner is
>>>> illegal? I would be very surprised if it was. It perfectly matches the
>>>> license exception cited above. And even without the exception, a closed
>>>> driver in userspace would only very unlikely be a derived work of the
>>>> kernel.
>>>
>>> I think we're diverging from the subject. Most of those discussions are
>>> interesting on some lawyers forum, not here.
>>>
>>> My view about this subject is that vtuner can't give any additional permissions
>>> to the kernel GPL'd code, as vtuner were not made by the Kernel Copyright owners,
>>> nor were approved by them. So, the extra permission at the COPYING clause
>>> from kernel doesn't apply here, while the code is not merged into the Kernel.
>>>
>>> So, while it should be legal to use vtuner with a GPL'd client application,
>>> using it by a closed source application violates GPL.
>>>
>>> My understanding is that an addition of a code that exposes the internal
>>> DVB core API to userspace like that will require that all dvb developers
>>> that have copyright rights at the dvb core should explicitly ack with such
>>> change, otherwise adding such code will violate the original license.
>>>
>>> On the other hand, if vtunerc won't act as a proxy to userspace, it should
>>> probably be ok.
>>
>> Are you serious? Why there is not same violation on NFS? Or even beter
>> example NBD (network block device)? It sits in kernel for ages and nobody
>> cares. It looks for me like you should send some patch for removal such
>> "weak" places in kernel which allow to violate GPL.
>>
>> Do you really think that it is possible (in real, no in threory) to create
>> any networked subsystem for sharing anything over net the way
>> when it is not exposed (somehow) to the userspace? How will be
>> such system managable? Why there is usually companion daemon
>> there, which is responsible for managing connections etc?
>>
>> I think it is very evident you want find the way how to get yours word
>> back and return to your original position = such code is not acceptable.
>> Even if you still are not able to give anything clear.
>>
>> If I understand your last few mails, you won't accept such driver, isn't it?
>
> You got wrong. You can't change someone's else license without their acks.

That I understand very well. I never want to force anybody to change
his licence.

I simply don't believe you that it is necessary. Why the same was not needed
with USBIP driver? If you check theirs nice big picture on
http://usbip.sourceforge.net/
you see that it is exactly same technology like vtunerc, but for USB subsystem.
Why such driver exists at all?

And I'm sure I can find more examples inside kernel tree. What about NBD
(http://nbd.sourceforge.net)? Do you want find me more examples?

> It is as simple as that. Getting everybody's ack is not that hard, if they
> accept that what you're doing is the right thing. We've got everybody's
> ack in the past to change the licensing for videodev2.h for example, to allow
> using the V4L2 API under BSD license (just the license API was changed, not the
> code itself).
>
>>> If people have different understandings, then we'll likely need to ask some
>>> support from Open source lawyers about this subject.
>>
>> My very little opinion is that waving GPL is way to the hell. Nobody told me
>> why similar technologies, in different kernel parts are acceptable,
>> but not here.
>
> If you want to do the networking code at userspace, why do you need a kernel
> driver after all? The proper solution is to write an userspace library for that,
> and either enclose such library inside the applications, or use LD_PRELOAD to
> bind the library to handle the open/close/ioctl glibc calls. libv4l does that.
> As it proofed to be a good library, now almost all V4L applications are using
> it.

LD_PELOAD is out of bussiness for normal work. It is technique for development
and/or debugging. Library would be possible, but then you kill main advantage
- totally independece of changes inside userland DVB applications.

And about networking in userspace - do you know other way then using
userspace daemon for management of connections and other control
jobs? Can you describe me how to do it w/o userspace application (daemon).
Why all are using it? Check networking filesystems.

I hope you can learn me how to do it correct way. I'm open for any
discussion. But no talks like "it breaks GPL" without any evident
argument from you.

/Honza

Re: [RFC] vtunerc - virtual DVB device driver

[Mauro Carvalho Chehab]

Em 22-06-2011 09:30, Andreas Oberritter escreveu:
> On 06/22/2011 02:17 PM, Mauro Carvalho Chehab wrote:
>> Em 21-06-2011 14:38, HoP escreveu:
>>> 2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>> Em 21-06-2011 12:09, Andreas Oberritter escreveu:
>>>>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
>>>>>> Em 21-06-2011 11:15, Andreas Oberritter escreveu:
>>>>>>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
>>>>>>>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
>>>>>>>>> Mauro and Devin, I think you're missing the point. This is not about
>>>>>>>>> creating drivers in userspace. This is not about open or closed source.
>>>>>>>>> The "vtuner" interface, as implemented for the Dreambox, is used to
>>>>>>>>> access remote tuners: Put x tuners into y boxes and access them from
>>>>>>>>> another box as if they were local. It's used in conjunction with further
>>>>>>>>> software to receive the transport stream over a network connection.
>>>>>>>>> Honza's code does the same thing.
>>>>>>>>
>>>>>>>> I'm not missing the point at all.  I realize exactly what Honza is
>>>>>>>> trying to accomplish (and from a purely technical standpoint, it's not
>>>>>>>> a bad approach) - but I'm talking about the effects of such a driver
>>>>>>>> being introduced which changes the kernel/userland licensing boundary
>>>>>>>> and has very real implications with how the in-kernel code is
>>>>>>>> accessed.
>>>>>>>>
>>>>>>>>> You don't need it in order to create closed source drivers. You can
>>>>>>>>> already create closed kernel drivers now. Also, you can create tuner
>>>>>>>>> drivers in userspace using the i2c-dev interface. If you like to connect
>>>>>>>>> a userspace driver to a DVB API device node, you can distribute a small
>>>>>>>>> (open or closed) wrapper with it. So what are you arguing about?
>>>>>>>>> Everything you're feared of can already be done since virtually forever.
>>>>>>>>
>>>>>>>> I disagree.  There is currently no API which allows applications to
>>>>>>>> issue tuning requests into the DVB core, and have those requests
>>>>>>>> proxied back out to userland where an application can then use i2c-dev
>>>>>>>> to tune the actual device.  Meaning if somebody wants to write a
>>>>>>>> closed source userland application which controls the tuner, he/she
>>>>>>>> can do that (while not conforming to the DVB API).  But if if he wants
>>>>>>>> to reuse the GPL licensed DVB core, he has to replace the entire DVB
>>>>>>>> core.
>>>>>>>>
>>>>>>>> The introduction of this patch makes it trivial for a third party to
>>>>>>>> provide closed-source userland support for tuners while reusing all
>>>>>>>> the existing GPL driver code that makes up the framework.
>>>>>>>>
>>>>>>>> I used to work for a vendor that makes tuners, and they do a bunch of
>>>>>>>> Linux work.  And that work has resulted in a bunch of open source
>>>>>>>> drivers.  I can tell you though that *every* conversation I've had
>>>>>>>> regarding a new driver goes something like this:
>>>>>>>>
>>>>>>>> ===
>>>>>>>> "Devin, we need to support tuner X under Linux."
>>>>>>>>
>>>>>>>> "Great!  I'll be happy to write a new GPL driver for the
>>>>>>>> tuner/demodulator/whatever for that device"
>>>>>>>>
>>>>>>>> "But to save time/money, we just want to reuse the Windows driver code
>>>>>>>> (or reference code from the vendor)."
>>>>>>>>
>>>>>>>> "Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"
>>>>>>>>
>>>>>>>> "Not currently.  So can we just make our driver closed source?"
>>>>>>>>
>>>>>>>> "Well, you can't reuse any of the existing DVB core functionality or
>>>>>>>> any of the other GPL drivers (tuners, bridges, demods), so you would
>>>>>>>> have rewrite all that from scratch."
>>>>>>>>
>>>>>>>> "Oh, that would be a ton of work.   Can we maybe write some userland
>>>>>>>> stuff that controls the demodulator which we can keep closed source?
>>>>>>>> Since it's not in the kernel, the GPL won't apply".
>>>>>>>>
>>>>>>>> "Well, you can't really do that because there is no way for the DVB
>>>>>>>> core to call back out to userland when the application makes the
>>>>>>>> tuning request to the DVB core."
>>>>>>>>
>>>>>>>> "Oh, ok then.  I guess we'll have to talk to the vendor and get them
>>>>>>>> to give us the reference driver code under the GPL."
>>>>>>>> ===
>>>>>>>>
>>>>>>>> I can tell you without a doubt that if this driver were present in the
>>>>>>>> kernel, that going forward that vendor would have *zero* interest in
>>>>>>>> doing any GPL driver work.  Why would they?  Why give away the code
>>>>>>>> which could potentially help their competitors if they can keep it
>>>>>>>> safe and protected while still being able to reuse everybody else's
>>>>>>>> contributions?
>>>>>>>>
>>>>>>>> Companies don't contribute GPL code out of "good will".  They do it
>>>>>>>> because they are compelled to by licenses or because there is no
>>>>>>>> economically viable alternative.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> Anyway, I said in my last email that would be my last email on the
>>>>>>>> topic.  I guess I lied.
>>>>>>>
>>>>>>> Yes, and you did lie to your vendor, too, as you did not mention the
>>>>>>> possibilities to create
>>>>>>> 1.) closed source modules derived from existing vendor drivers while
>>>>>>> still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
>>>>>>> EXPORT_SYMBOL_GPL).
>>>>>>
>>>>>> AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL
>>>>>> are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly
>>>>>> adds a restriction, not using it doesn't necessarily mean that the symbol
>>>>>> can be used by a closed source driver.
>>>>>>
>>>>>> If you take a look at Kernel's COPYING file, the only exception to GPL license
>>>>>> allowed there is:
>>>>>>
>>>>>>       NOTE! This copyright does *not* cover user programs that use kernel
>>>>>>       services by normal system calls - this is merely considered normal use
>>>>>>       of the kernel, and does *not* fall under the heading of "derived work".
>>>>>>
>>>>>> IANAL, but, as EXPORT_SYMBOL is not a "normal system call", my understanding is that
>>>>>> it is also covered by GPL.
>>>>>
>>>>> Of course. But as you should know, the GPL only covers derived work.
>>>>> Whether or not a driver is a derived work of the kernel can only be
>>>>> decided individually. It is my understanding that a Windows driver
>>>>> ported to Linux is unlikely to be a derived work of Linux.
>>>>>
>>>>>> I was told that several lawyers defend the idea that all software inside the
>>>>>> kernel tree is covered by GPL, even the aggregated ones. That was the rationale
>>>>>> used to split the firmware packages from the kernel itself.
>>>>>
>>>>> However, I wasn't referring to the kernel tree at all.
>>>>>
>>>>>>> 2.) a simple wrapper that calls userspace, therefore not having to open
>>>>>>> up any "secrets" at all.
>>>>>>
>>>>>> A wrapper for a closed source driver is illegal, as it is trying to circumvent
>>>>>> the GPL license.
>>>>>
>>>>> Is it? First, you are not a lawyer. Second, a wrapper is unlikely to be
>>>>> illegal by its pure existence and a wrapper does usually not try to do
>>>>> anything by itself. Third, you can implement a wrapper using normal
>>>>> system calls (read, write, mmap, ioctl ...). That's what vtuner does,
>>>>> too, to accomplish a totally different goal. Do you think vtuner is
>>>>> illegal? I would be very surprised if it was. It perfectly matches the
>>>>> license exception cited above. And even without the exception, a closed
>>>>> driver in userspace would only very unlikely be a derived work of the
>>>>> kernel.
>>>>
>>>> I think we're diverging from the subject. Most of those discussions are
>>>> interesting on some lawyers forum, not here.
>>>>
>>>> My view about this subject is that vtuner can't give any additional permissions
>>>> to the kernel GPL'd code, as vtuner were not made by the Kernel Copyright owners,
>>>> nor were approved by them. So, the extra permission at the COPYING clause
>>>> from kernel doesn't apply here, while the code is not merged into the Kernel.
>>>>
>>>> So, while it should be legal to use vtuner with a GPL'd client application,
>>>> using it by a closed source application violates GPL.
>>>>
>>>> My understanding is that an addition of a code that exposes the internal
>>>> DVB core API to userspace like that will require that all dvb developers
>>>> that have copyright rights at the dvb core should explicitly ack with such
>>>> change, otherwise adding such code will violate the original license.
>>>>
>>>> On the other hand, if vtunerc won't act as a proxy to userspace, it should
>>>> probably be ok.
>>>
>>> Are you serious? Why there is not same violation on NFS? Or even beter
>>> example NBD (network block device)? It sits in kernel for ages and nobody
>>> cares. It looks for me like you should send some patch for removal such
>>> "weak" places in kernel which allow to violate GPL.
>>>
>>> Do you really think that it is possible (in real, no in threory) to create
>>> any networked subsystem for sharing anything over net the way
>>> when it is not exposed (somehow) to the userspace? How will be
>>> such system managable? Why there is usually companion daemon
>>> there, which is responsible for managing connections etc?
>>>
>>> I think it is very evident you want find the way how to get yours word
>>> back and return to your original position = such code is not acceptable.
>>> Even if you still are not able to give anything clear.
>>>
>>> If I understand your last few mails, you won't accept such driver, isn't it?
>>
>> You got wrong. You can't change someone's else license without their acks.
>> It is as simple as that. Getting everybody's ack is not that hard, if they
>> accept that what you're doing is the right thing. We've got everybody's
>> ack in the past to change the licensing for videodev2.h for example, to allow
>> using the V4L2 API under BSD license (just the license API was changed, not the
>> code itself).
> 
> Is there anybode else who thinks that adding GPL'd code to the GPL'd
> kernel would require any change in licensing? This is insane. What
> change to whose license are you referring to, please?

Kernel licensing is not a pure GPL license. If it were a pure GPL license, all software
that would run on the top of it would need to also be released under GPL.

Kernel license is GPLv2 + additional rights to allow binary code to run on the top 
of it, for the system calls that are introduced in order to allow the usage of
the hardware resources managed by the Kernel (drivers, network, memory, CPU's, etc).

There are no doubts that dvb developers wanted their drivers to be controlled from
userspace, but, from previous discussions about this subject, several developers
explicitly said that they didn't want to allow any kind of wrapper module to be added.

Mauro.

Re: [RFC] vtunerc - virtual DVB device driver

[Mauro Carvalho Chehab]

Em 22-06-2011 09:37, HoP escreveu:
> 2011/6/22 Mauro Carvalho Chehab <mchehab@redhat.com>:
>> Em 21-06-2011 14:38, HoP escreveu:
>>> 2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>> Em 21-06-2011 12:09, Andreas Oberritter escreveu:
>>>>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
>>>>>> Em 21-06-2011 11:15, Andreas Oberritter escreveu:
>>>>>>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
>>>>>>>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
>>>>>>>>> Mauro and Devin, I think you're missing the point. This is not about
>>>>>>>>> creating drivers in userspace. This is not about open or closed source.
>>>>>>>>> The "vtuner" interface, as implemented for the Dreambox, is used to
>>>>>>>>> access remote tuners: Put x tuners into y boxes and access them from
>>>>>>>>> another box as if they were local. It's used in conjunction with further
>>>>>>>>> software to receive the transport stream over a network connection.
>>>>>>>>> Honza's code does the same thing.
>>>>>>>>
>>>>>>>> I'm not missing the point at all.  I realize exactly what Honza is
>>>>>>>> trying to accomplish (and from a purely technical standpoint, it's not
>>>>>>>> a bad approach) - but I'm talking about the effects of such a driver
>>>>>>>> being introduced which changes the kernel/userland licensing boundary
>>>>>>>> and has very real implications with how the in-kernel code is
>>>>>>>> accessed.
>>>>>>>>
>>>>>>>>> You don't need it in order to create closed source drivers. You can
>>>>>>>>> already create closed kernel drivers now. Also, you can create tuner
>>>>>>>>> drivers in userspace using the i2c-dev interface. If you like to connect
>>>>>>>>> a userspace driver to a DVB API device node, you can distribute a small
>>>>>>>>> (open or closed) wrapper with it. So what are you arguing about?
>>>>>>>>> Everything you're feared of can already be done since virtually forever.
>>>>>>>>
>>>>>>>> I disagree.  There is currently no API which allows applications to
>>>>>>>> issue tuning requests into the DVB core, and have those requests
>>>>>>>> proxied back out to userland where an application can then use i2c-dev
>>>>>>>> to tune the actual device.  Meaning if somebody wants to write a
>>>>>>>> closed source userland application which controls the tuner, he/she
>>>>>>>> can do that (while not conforming to the DVB API).  But if if he wants
>>>>>>>> to reuse the GPL licensed DVB core, he has to replace the entire DVB
>>>>>>>> core.
>>>>>>>>
>>>>>>>> The introduction of this patch makes it trivial for a third party to
>>>>>>>> provide closed-source userland support for tuners while reusing all
>>>>>>>> the existing GPL driver code that makes up the framework.
>>>>>>>>
>>>>>>>> I used to work for a vendor that makes tuners, and they do a bunch of
>>>>>>>> Linux work.  And that work has resulted in a bunch of open source
>>>>>>>> drivers.  I can tell you though that *every* conversation I've had
>>>>>>>> regarding a new driver goes something like this:
>>>>>>>>
>>>>>>>> ===
>>>>>>>> "Devin, we need to support tuner X under Linux."
>>>>>>>>
>>>>>>>> "Great!  I'll be happy to write a new GPL driver for the
>>>>>>>> tuner/demodulator/whatever for that device"
>>>>>>>>
>>>>>>>> "But to save time/money, we just want to reuse the Windows driver code
>>>>>>>> (or reference code from the vendor)."
>>>>>>>>
>>>>>>>> "Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"
>>>>>>>>
>>>>>>>> "Not currently.  So can we just make our driver closed source?"
>>>>>>>>
>>>>>>>> "Well, you can't reuse any of the existing DVB core functionality or
>>>>>>>> any of the other GPL drivers (tuners, bridges, demods), so you would
>>>>>>>> have rewrite all that from scratch."
>>>>>>>>
>>>>>>>> "Oh, that would be a ton of work.   Can we maybe write some userland
>>>>>>>> stuff that controls the demodulator which we can keep closed source?
>>>>>>>> Since it's not in the kernel, the GPL won't apply".
>>>>>>>>
>>>>>>>> "Well, you can't really do that because there is no way for the DVB
>>>>>>>> core to call back out to userland when the application makes the
>>>>>>>> tuning request to the DVB core."
>>>>>>>>
>>>>>>>> "Oh, ok then.  I guess we'll have to talk to the vendor and get them
>>>>>>>> to give us the reference driver code under the GPL."
>>>>>>>> ===
>>>>>>>>
>>>>>>>> I can tell you without a doubt that if this driver were present in the
>>>>>>>> kernel, that going forward that vendor would have *zero* interest in
>>>>>>>> doing any GPL driver work.  Why would they?  Why give away the code
>>>>>>>> which could potentially help their competitors if they can keep it
>>>>>>>> safe and protected while still being able to reuse everybody else's
>>>>>>>> contributions?
>>>>>>>>
>>>>>>>> Companies don't contribute GPL code out of "good will".  They do it
>>>>>>>> because they are compelled to by licenses or because there is no
>>>>>>>> economically viable alternative.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> Anyway, I said in my last email that would be my last email on the
>>>>>>>> topic.  I guess I lied.
>>>>>>>
>>>>>>> Yes, and you did lie to your vendor, too, as you did not mention the
>>>>>>> possibilities to create
>>>>>>> 1.) closed source modules derived from existing vendor drivers while
>>>>>>> still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
>>>>>>> EXPORT_SYMBOL_GPL).
>>>>>>
>>>>>> AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL
>>>>>> are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly
>>>>>> adds a restriction, not using it doesn't necessarily mean that the symbol
>>>>>> can be used by a closed source driver.
>>>>>>
>>>>>> If you take a look at Kernel's COPYING file, the only exception to GPL license
>>>>>> allowed there is:
>>>>>>
>>>>>>       NOTE! This copyright does *not* cover user programs that use kernel
>>>>>>       services by normal system calls - this is merely considered normal use
>>>>>>       of the kernel, and does *not* fall under the heading of "derived work".
>>>>>>
>>>>>> IANAL, but, as EXPORT_SYMBOL is not a "normal system call", my understanding is that
>>>>>> it is also covered by GPL.
>>>>>
>>>>> Of course. But as you should know, the GPL only covers derived work.
>>>>> Whether or not a driver is a derived work of the kernel can only be
>>>>> decided individually. It is my understanding that a Windows driver
>>>>> ported to Linux is unlikely to be a derived work of Linux.
>>>>>
>>>>>> I was told that several lawyers defend the idea that all software inside the
>>>>>> kernel tree is covered by GPL, even the aggregated ones. That was the rationale
>>>>>> used to split the firmware packages from the kernel itself.
>>>>>
>>>>> However, I wasn't referring to the kernel tree at all.
>>>>>
>>>>>>> 2.) a simple wrapper that calls userspace, therefore not having to open
>>>>>>> up any "secrets" at all.
>>>>>>
>>>>>> A wrapper for a closed source driver is illegal, as it is trying to circumvent
>>>>>> the GPL license.
>>>>>
>>>>> Is it? First, you are not a lawyer. Second, a wrapper is unlikely to be
>>>>> illegal by its pure existence and a wrapper does usually not try to do
>>>>> anything by itself. Third, you can implement a wrapper using normal
>>>>> system calls (read, write, mmap, ioctl ...). That's what vtuner does,
>>>>> too, to accomplish a totally different goal. Do you think vtuner is
>>>>> illegal? I would be very surprised if it was. It perfectly matches the
>>>>> license exception cited above. And even without the exception, a closed
>>>>> driver in userspace would only very unlikely be a derived work of the
>>>>> kernel.
>>>>
>>>> I think we're diverging from the subject. Most of those discussions are
>>>> interesting on some lawyers forum, not here.
>>>>
>>>> My view about this subject is that vtuner can't give any additional permissions
>>>> to the kernel GPL'd code, as vtuner were not made by the Kernel Copyright owners,
>>>> nor were approved by them. So, the extra permission at the COPYING clause
>>>> from kernel doesn't apply here, while the code is not merged into the Kernel.
>>>>
>>>> So, while it should be legal to use vtuner with a GPL'd client application,
>>>> using it by a closed source application violates GPL.
>>>>
>>>> My understanding is that an addition of a code that exposes the internal
>>>> DVB core API to userspace like that will require that all dvb developers
>>>> that have copyright rights at the dvb core should explicitly ack with such
>>>> change, otherwise adding such code will violate the original license.
>>>>
>>>> On the other hand, if vtunerc won't act as a proxy to userspace, it should
>>>> probably be ok.
>>>
>>> Are you serious? Why there is not same violation on NFS? Or even beter
>>> example NBD (network block device)? It sits in kernel for ages and nobody
>>> cares. It looks for me like you should send some patch for removal such
>>> "weak" places in kernel which allow to violate GPL.
>>>
>>> Do you really think that it is possible (in real, no in threory) to create
>>> any networked subsystem for sharing anything over net the way
>>> when it is not exposed (somehow) to the userspace? How will be
>>> such system managable? Why there is usually companion daemon
>>> there, which is responsible for managing connections etc?
>>>
>>> I think it is very evident you want find the way how to get yours word
>>> back and return to your original position = such code is not acceptable.
>>> Even if you still are not able to give anything clear.
>>>
>>> If I understand your last few mails, you won't accept such driver, isn't it?
>>
>> You got wrong. You can't change someone's else license without their acks.
> 
> That I understand very well. I never want to force anybody to change
> his licence.
> 
> I simply don't believe you that it is necessary. Why the same was not needed
> with USBIP driver? If you check theirs nice big picture on
> http://usbip.sourceforge.net/
> you see that it is exactly same technology like vtunerc, but for USB subsystem.
> Why such driver exists at all?
> 
> And I'm sure I can find more examples inside kernel tree. What about NBD
> (http://nbd.sourceforge.net)? Do you want find me more examples?
> 
>> It is as simple as that. Getting everybody's ack is not that hard, if they
>> accept that what you're doing is the right thing. We've got everybody's
>> ack in the past to change the licensing for videodev2.h for example, to allow
>> using the V4L2 API under BSD license (just the license API was changed, not the
>> code itself).
>>
>>>> If people have different understandings, then we'll likely need to ask some
>>>> support from Open source lawyers about this subject.
>>>
>>> My very little opinion is that waving GPL is way to the hell. Nobody told me
>>> why similar technologies, in different kernel parts are acceptable,
>>> but not here.
>>
>> If you want to do the networking code at userspace, why do you need a kernel
>> driver after all? The proper solution is to write an userspace library for that,
>> and either enclose such library inside the applications, or use LD_PRELOAD to
>> bind the library to handle the open/close/ioctl glibc calls. libv4l does that.
>> As it proofed to be a good library, now almost all V4L applications are using
>> it.
> 
> LD_PELOAD is out of bussiness for normal work. It is technique for development
> and/or debugging.

Well, libv4l successfully uses LD_PRELOAD in order to support all applications 
that weren't ported to it yet. It offers two ways:
	1) you can use it as a normal library;
	2) you can use it with LD_PRELOAD.


> Library would be possible, but then you kill main advantage
> - totally independece of changes inside userland DVB applications.

Why? if you write a "dvb_open", "dvb_ioctl", ... methods with the same syntax of
glibc open, ioctl, ..., the efforts to migrate an userspace application to use it
is to just run:
	sed s,open,dvb_open,g
	sed s,ioctl,dvb_ioctl,g


The library and the application will be completely independent.

On the other hand, if you put it at kernelspace, you'll need to have an stable
userspace API for every ioctl, as we don't allow userspace API breakages. So,
new features will need to be backward compatible.
 
Cheers,
Mauro

Re: [RFC] vtunerc - virtual DVB device driver

[Andreas Oberritter]

On 06/22/2011 02:55 PM, Mauro Carvalho Chehab wrote:
> Em 22-06-2011 09:30, Andreas Oberritter escreveu:
>> On 06/22/2011 02:17 PM, Mauro Carvalho Chehab wrote:
>>> Em 21-06-2011 14:38, HoP escreveu:
>>>> 2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>>> Em 21-06-2011 12:09, Andreas Oberritter escreveu:
>>>>>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
>>>>>>> Em 21-06-2011 11:15, Andreas Oberritter escreveu:
>>>>>>>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
>>>>>>>>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
>>>>>>>>>> Mauro and Devin, I think you're missing the point. This is not about
>>>>>>>>>> creating drivers in userspace. This is not about open or closed source.
>>>>>>>>>> The "vtuner" interface, as implemented for the Dreambox, is used to
>>>>>>>>>> access remote tuners: Put x tuners into y boxes and access them from
>>>>>>>>>> another box as if they were local. It's used in conjunction with further
>>>>>>>>>> software to receive the transport stream over a network connection.
>>>>>>>>>> Honza's code does the same thing.
>>>>>>>>>
>>>>>>>>> I'm not missing the point at all.  I realize exactly what Honza is
>>>>>>>>> trying to accomplish (and from a purely technical standpoint, it's not
>>>>>>>>> a bad approach) - but I'm talking about the effects of such a driver
>>>>>>>>> being introduced which changes the kernel/userland licensing boundary
>>>>>>>>> and has very real implications with how the in-kernel code is
>>>>>>>>> accessed.
>>>>>>>>>
>>>>>>>>>> You don't need it in order to create closed source drivers. You can
>>>>>>>>>> already create closed kernel drivers now. Also, you can create tuner
>>>>>>>>>> drivers in userspace using the i2c-dev interface. If you like to connect
>>>>>>>>>> a userspace driver to a DVB API device node, you can distribute a small
>>>>>>>>>> (open or closed) wrapper with it. So what are you arguing about?
>>>>>>>>>> Everything you're feared of can already be done since virtually forever.
>>>>>>>>>
>>>>>>>>> I disagree.  There is currently no API which allows applications to
>>>>>>>>> issue tuning requests into the DVB core, and have those requests
>>>>>>>>> proxied back out to userland where an application can then use i2c-dev
>>>>>>>>> to tune the actual device.  Meaning if somebody wants to write a
>>>>>>>>> closed source userland application which controls the tuner, he/she
>>>>>>>>> can do that (while not conforming to the DVB API).  But if if he wants
>>>>>>>>> to reuse the GPL licensed DVB core, he has to replace the entire DVB
>>>>>>>>> core.
>>>>>>>>>
>>>>>>>>> The introduction of this patch makes it trivial for a third party to
>>>>>>>>> provide closed-source userland support for tuners while reusing all
>>>>>>>>> the existing GPL driver code that makes up the framework.
>>>>>>>>>
>>>>>>>>> I used to work for a vendor that makes tuners, and they do a bunch of
>>>>>>>>> Linux work.  And that work has resulted in a bunch of open source
>>>>>>>>> drivers.  I can tell you though that *every* conversation I've had
>>>>>>>>> regarding a new driver goes something like this:
>>>>>>>>>
>>>>>>>>> ===
>>>>>>>>> "Devin, we need to support tuner X under Linux."
>>>>>>>>>
>>>>>>>>> "Great!  I'll be happy to write a new GPL driver for the
>>>>>>>>> tuner/demodulator/whatever for that device"
>>>>>>>>>
>>>>>>>>> "But to save time/money, we just want to reuse the Windows driver code
>>>>>>>>> (or reference code from the vendor)."
>>>>>>>>>
>>>>>>>>> "Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"
>>>>>>>>>
>>>>>>>>> "Not currently.  So can we just make our driver closed source?"
>>>>>>>>>
>>>>>>>>> "Well, you can't reuse any of the existing DVB core functionality or
>>>>>>>>> any of the other GPL drivers (tuners, bridges, demods), so you would
>>>>>>>>> have rewrite all that from scratch."
>>>>>>>>>
>>>>>>>>> "Oh, that would be a ton of work.   Can we maybe write some userland
>>>>>>>>> stuff that controls the demodulator which we can keep closed source?
>>>>>>>>> Since it's not in the kernel, the GPL won't apply".
>>>>>>>>>
>>>>>>>>> "Well, you can't really do that because there is no way for the DVB
>>>>>>>>> core to call back out to userland when the application makes the
>>>>>>>>> tuning request to the DVB core."
>>>>>>>>>
>>>>>>>>> "Oh, ok then.  I guess we'll have to talk to the vendor and get them
>>>>>>>>> to give us the reference driver code under the GPL."
>>>>>>>>> ===
>>>>>>>>>
>>>>>>>>> I can tell you without a doubt that if this driver were present in the
>>>>>>>>> kernel, that going forward that vendor would have *zero* interest in
>>>>>>>>> doing any GPL driver work.  Why would they?  Why give away the code
>>>>>>>>> which could potentially help their competitors if they can keep it
>>>>>>>>> safe and protected while still being able to reuse everybody else's
>>>>>>>>> contributions?
>>>>>>>>>
>>>>>>>>> Companies don't contribute GPL code out of "good will".  They do it
>>>>>>>>> because they are compelled to by licenses or because there is no
>>>>>>>>> economically viable alternative.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> Anyway, I said in my last email that would be my last email on the
>>>>>>>>> topic.  I guess I lied.
>>>>>>>>
>>>>>>>> Yes, and you did lie to your vendor, too, as you did not mention the
>>>>>>>> possibilities to create
>>>>>>>> 1.) closed source modules derived from existing vendor drivers while
>>>>>>>> still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
>>>>>>>> EXPORT_SYMBOL_GPL).
>>>>>>>
>>>>>>> AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL
>>>>>>> are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly
>>>>>>> adds a restriction, not using it doesn't necessarily mean that the symbol
>>>>>>> can be used by a closed source driver.
>>>>>>>
>>>>>>> If you take a look at Kernel's COPYING file, the only exception to GPL license
>>>>>>> allowed there is:
>>>>>>>
>>>>>>>       NOTE! This copyright does *not* cover user programs that use kernel
>>>>>>>       services by normal system calls - this is merely considered normal use
>>>>>>>       of the kernel, and does *not* fall under the heading of "derived work".
>>>>>>>
>>>>>>> IANAL, but, as EXPORT_SYMBOL is not a "normal system call", my understanding is that
>>>>>>> it is also covered by GPL.
>>>>>>
>>>>>> Of course. But as you should know, the GPL only covers derived work.
>>>>>> Whether or not a driver is a derived work of the kernel can only be
>>>>>> decided individually. It is my understanding that a Windows driver
>>>>>> ported to Linux is unlikely to be a derived work of Linux.
>>>>>>
>>>>>>> I was told that several lawyers defend the idea that all software inside the
>>>>>>> kernel tree is covered by GPL, even the aggregated ones. That was the rationale
>>>>>>> used to split the firmware packages from the kernel itself.
>>>>>>
>>>>>> However, I wasn't referring to the kernel tree at all.
>>>>>>
>>>>>>>> 2.) a simple wrapper that calls userspace, therefore not having to open
>>>>>>>> up any "secrets" at all.
>>>>>>>
>>>>>>> A wrapper for a closed source driver is illegal, as it is trying to circumvent
>>>>>>> the GPL license.
>>>>>>
>>>>>> Is it? First, you are not a lawyer. Second, a wrapper is unlikely to be
>>>>>> illegal by its pure existence and a wrapper does usually not try to do
>>>>>> anything by itself. Third, you can implement a wrapper using normal
>>>>>> system calls (read, write, mmap, ioctl ...). That's what vtuner does,
>>>>>> too, to accomplish a totally different goal. Do you think vtuner is
>>>>>> illegal? I would be very surprised if it was. It perfectly matches the
>>>>>> license exception cited above. And even without the exception, a closed
>>>>>> driver in userspace would only very unlikely be a derived work of the
>>>>>> kernel.
>>>>>
>>>>> I think we're diverging from the subject. Most of those discussions are
>>>>> interesting on some lawyers forum, not here.
>>>>>
>>>>> My view about this subject is that vtuner can't give any additional permissions
>>>>> to the kernel GPL'd code, as vtuner were not made by the Kernel Copyright owners,
>>>>> nor were approved by them. So, the extra permission at the COPYING clause
>>>>> from kernel doesn't apply here, while the code is not merged into the Kernel.
>>>>>
>>>>> So, while it should be legal to use vtuner with a GPL'd client application,
>>>>> using it by a closed source application violates GPL.
>>>>>
>>>>> My understanding is that an addition of a code that exposes the internal
>>>>> DVB core API to userspace like that will require that all dvb developers
>>>>> that have copyright rights at the dvb core should explicitly ack with such
>>>>> change, otherwise adding such code will violate the original license.
>>>>>
>>>>> On the other hand, if vtunerc won't act as a proxy to userspace, it should
>>>>> probably be ok.
>>>>
>>>> Are you serious? Why there is not same violation on NFS? Or even beter
>>>> example NBD (network block device)? It sits in kernel for ages and nobody
>>>> cares. It looks for me like you should send some patch for removal such
>>>> "weak" places in kernel which allow to violate GPL.
>>>>
>>>> Do you really think that it is possible (in real, no in threory) to create
>>>> any networked subsystem for sharing anything over net the way
>>>> when it is not exposed (somehow) to the userspace? How will be
>>>> such system managable? Why there is usually companion daemon
>>>> there, which is responsible for managing connections etc?
>>>>
>>>> I think it is very evident you want find the way how to get yours word
>>>> back and return to your original position = such code is not acceptable.
>>>> Even if you still are not able to give anything clear.
>>>>
>>>> If I understand your last few mails, you won't accept such driver, isn't it?
>>>
>>> You got wrong. You can't change someone's else license without their acks.
>>> It is as simple as that. Getting everybody's ack is not that hard, if they
>>> accept that what you're doing is the right thing. We've got everybody's
>>> ack in the past to change the licensing for videodev2.h for example, to allow
>>> using the V4L2 API under BSD license (just the license API was changed, not the
>>> code itself).
>>
>> Is there anybode else who thinks that adding GPL'd code to the GPL'd
>> kernel would require any change in licensing? This is insane. What
>> change to whose license are you referring to, please?
> 
> Kernel licensing is not a pure GPL license. If it were a pure GPL license, all software
> that would run on the top of it would need to also be released under GPL.
> 
> Kernel license is GPLv2 + additional rights to allow binary code to run on the top 
> of it, for the system calls that are introduced in order to allow the usage of
> the hardware resources managed by the Kernel (drivers, network, memory, CPU's, etc).

Please stop explaining the kernel's license. Everyone knows it. And of
course, the vtuner code would also be licensed under the very same terms.

> There are no doubts that dvb developers wanted their drivers to be controlled from
> userspace, but, from previous discussions about this subject, several developers
> explicitly said that they didn't want to allow any kind of wrapper module to be added.

Aha! So several developers' opinions from the past are the reason and
not any licensing blah blah or technical reasons. Well, several other
developers explicitly said the opposite.

Did you even review the code by now? Did you realize that it's just
about remote tuners and not something like full DVB device virtualization?

Do you really want to put the networking into the kernel? How would you
for example use an SSL- or SSH-tunneled connection between two kernels
to transfer the data? Do you want to force plaintext transfers onto
users? Do you want to stick the yet-to-be-designed networking protocol
into the kernel, running with full privileges?

Regards,
Andreas

Re: [RFC] vtunerc - virtual DVB device driver

[Andreas Oberritter]

On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote:
> Em 22-06-2011 09:37, HoP escreveu:
>> 2011/6/22 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>> Em 21-06-2011 14:38, HoP escreveu:
>>>> 2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>>> Em 21-06-2011 12:09, Andreas Oberritter escreveu:
>>>>>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
>>>>>>> Em 21-06-2011 11:15, Andreas Oberritter escreveu:
>>>>>>>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
>>>>>>>>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
>>>>>>>>>> Mauro and Devin, I think you're missing the point. This is not about
>>>>>>>>>> creating drivers in userspace. This is not about open or closed source.
>>>>>>>>>> The "vtuner" interface, as implemented for the Dreambox, is used to
>>>>>>>>>> access remote tuners: Put x tuners into y boxes and access them from
>>>>>>>>>> another box as if they were local. It's used in conjunction with further
>>>>>>>>>> software to receive the transport stream over a network connection.
>>>>>>>>>> Honza's code does the same thing.
>>>>>>>>>
>>>>>>>>> I'm not missing the point at all.  I realize exactly what Honza is
>>>>>>>>> trying to accomplish (and from a purely technical standpoint, it's not
>>>>>>>>> a bad approach) - but I'm talking about the effects of such a driver
>>>>>>>>> being introduced which changes the kernel/userland licensing boundary
>>>>>>>>> and has very real implications with how the in-kernel code is
>>>>>>>>> accessed.
>>>>>>>>>
>>>>>>>>>> You don't need it in order to create closed source drivers. You can
>>>>>>>>>> already create closed kernel drivers now. Also, you can create tuner
>>>>>>>>>> drivers in userspace using the i2c-dev interface. If you like to connect
>>>>>>>>>> a userspace driver to a DVB API device node, you can distribute a small
>>>>>>>>>> (open or closed) wrapper with it. So what are you arguing about?
>>>>>>>>>> Everything you're feared of can already be done since virtually forever.
>>>>>>>>>
>>>>>>>>> I disagree.  There is currently no API which allows applications to
>>>>>>>>> issue tuning requests into the DVB core, and have those requests
>>>>>>>>> proxied back out to userland where an application can then use i2c-dev
>>>>>>>>> to tune the actual device.  Meaning if somebody wants to write a
>>>>>>>>> closed source userland application which controls the tuner, he/she
>>>>>>>>> can do that (while not conforming to the DVB API).  But if if he wants
>>>>>>>>> to reuse the GPL licensed DVB core, he has to replace the entire DVB
>>>>>>>>> core.
>>>>>>>>>
>>>>>>>>> The introduction of this patch makes it trivial for a third party to
>>>>>>>>> provide closed-source userland support for tuners while reusing all
>>>>>>>>> the existing GPL driver code that makes up the framework.
>>>>>>>>>
>>>>>>>>> I used to work for a vendor that makes tuners, and they do a bunch of
>>>>>>>>> Linux work.  And that work has resulted in a bunch of open source
>>>>>>>>> drivers.  I can tell you though that *every* conversation I've had
>>>>>>>>> regarding a new driver goes something like this:
>>>>>>>>>
>>>>>>>>> ===
>>>>>>>>> "Devin, we need to support tuner X under Linux."
>>>>>>>>>
>>>>>>>>> "Great!  I'll be happy to write a new GPL driver for the
>>>>>>>>> tuner/demodulator/whatever for that device"
>>>>>>>>>
>>>>>>>>> "But to save time/money, we just want to reuse the Windows driver code
>>>>>>>>> (or reference code from the vendor)."
>>>>>>>>>
>>>>>>>>> "Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"
>>>>>>>>>
>>>>>>>>> "Not currently.  So can we just make our driver closed source?"
>>>>>>>>>
>>>>>>>>> "Well, you can't reuse any of the existing DVB core functionality or
>>>>>>>>> any of the other GPL drivers (tuners, bridges, demods), so you would
>>>>>>>>> have rewrite all that from scratch."
>>>>>>>>>
>>>>>>>>> "Oh, that would be a ton of work.   Can we maybe write some userland
>>>>>>>>> stuff that controls the demodulator which we can keep closed source?
>>>>>>>>> Since it's not in the kernel, the GPL won't apply".
>>>>>>>>>
>>>>>>>>> "Well, you can't really do that because there is no way for the DVB
>>>>>>>>> core to call back out to userland when the application makes the
>>>>>>>>> tuning request to the DVB core."
>>>>>>>>>
>>>>>>>>> "Oh, ok then.  I guess we'll have to talk to the vendor and get them
>>>>>>>>> to give us the reference driver code under the GPL."
>>>>>>>>> ===
>>>>>>>>>
>>>>>>>>> I can tell you without a doubt that if this driver were present in the
>>>>>>>>> kernel, that going forward that vendor would have *zero* interest in
>>>>>>>>> doing any GPL driver work.  Why would they?  Why give away the code
>>>>>>>>> which could potentially help their competitors if they can keep it
>>>>>>>>> safe and protected while still being able to reuse everybody else's
>>>>>>>>> contributions?
>>>>>>>>>
>>>>>>>>> Companies don't contribute GPL code out of "good will".  They do it
>>>>>>>>> because they are compelled to by licenses or because there is no
>>>>>>>>> economically viable alternative.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> Anyway, I said in my last email that would be my last email on the
>>>>>>>>> topic.  I guess I lied.
>>>>>>>>
>>>>>>>> Yes, and you did lie to your vendor, too, as you did not mention the
>>>>>>>> possibilities to create
>>>>>>>> 1.) closed source modules derived from existing vendor drivers while
>>>>>>>> still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
>>>>>>>> EXPORT_SYMBOL_GPL).
>>>>>>>
>>>>>>> AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL
>>>>>>> are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly
>>>>>>> adds a restriction, not using it doesn't necessarily mean that the symbol
>>>>>>> can be used by a closed source driver.
>>>>>>>
>>>>>>> If you take a look at Kernel's COPYING file, the only exception to GPL license
>>>>>>> allowed there is:
>>>>>>>
>>>>>>>       NOTE! This copyright does *not* cover user programs that use kernel
>>>>>>>       services by normal system calls - this is merely considered normal use
>>>>>>>       of the kernel, and does *not* fall under the heading of "derived work".
>>>>>>>
>>>>>>> IANAL, but, as EXPORT_SYMBOL is not a "normal system call", my understanding is that
>>>>>>> it is also covered by GPL.
>>>>>>
>>>>>> Of course. But as you should know, the GPL only covers derived work.
>>>>>> Whether or not a driver is a derived work of the kernel can only be
>>>>>> decided individually. It is my understanding that a Windows driver
>>>>>> ported to Linux is unlikely to be a derived work of Linux.
>>>>>>
>>>>>>> I was told that several lawyers defend the idea that all software inside the
>>>>>>> kernel tree is covered by GPL, even the aggregated ones. That was the rationale
>>>>>>> used to split the firmware packages from the kernel itself.
>>>>>>
>>>>>> However, I wasn't referring to the kernel tree at all.
>>>>>>
>>>>>>>> 2.) a simple wrapper that calls userspace, therefore not having to open
>>>>>>>> up any "secrets" at all.
>>>>>>>
>>>>>>> A wrapper for a closed source driver is illegal, as it is trying to circumvent
>>>>>>> the GPL license.
>>>>>>
>>>>>> Is it? First, you are not a lawyer. Second, a wrapper is unlikely to be
>>>>>> illegal by its pure existence and a wrapper does usually not try to do
>>>>>> anything by itself. Third, you can implement a wrapper using normal
>>>>>> system calls (read, write, mmap, ioctl ...). That's what vtuner does,
>>>>>> too, to accomplish a totally different goal. Do you think vtuner is
>>>>>> illegal? I would be very surprised if it was. It perfectly matches the
>>>>>> license exception cited above. And even without the exception, a closed
>>>>>> driver in userspace would only very unlikely be a derived work of the
>>>>>> kernel.
>>>>>
>>>>> I think we're diverging from the subject. Most of those discussions are
>>>>> interesting on some lawyers forum, not here.
>>>>>
>>>>> My view about this subject is that vtuner can't give any additional permissions
>>>>> to the kernel GPL'd code, as vtuner were not made by the Kernel Copyright owners,
>>>>> nor were approved by them. So, the extra permission at the COPYING clause
>>>>> from kernel doesn't apply here, while the code is not merged into the Kernel.
>>>>>
>>>>> So, while it should be legal to use vtuner with a GPL'd client application,
>>>>> using it by a closed source application violates GPL.
>>>>>
>>>>> My understanding is that an addition of a code that exposes the internal
>>>>> DVB core API to userspace like that will require that all dvb developers
>>>>> that have copyright rights at the dvb core should explicitly ack with such
>>>>> change, otherwise adding such code will violate the original license.
>>>>>
>>>>> On the other hand, if vtunerc won't act as a proxy to userspace, it should
>>>>> probably be ok.
>>>>
>>>> Are you serious? Why there is not same violation on NFS? Or even beter
>>>> example NBD (network block device)? It sits in kernel for ages and nobody
>>>> cares. It looks for me like you should send some patch for removal such
>>>> "weak" places in kernel which allow to violate GPL.
>>>>
>>>> Do you really think that it is possible (in real, no in threory) to create
>>>> any networked subsystem for sharing anything over net the way
>>>> when it is not exposed (somehow) to the userspace? How will be
>>>> such system managable? Why there is usually companion daemon
>>>> there, which is responsible for managing connections etc?
>>>>
>>>> I think it is very evident you want find the way how to get yours word
>>>> back and return to your original position = such code is not acceptable.
>>>> Even if you still are not able to give anything clear.
>>>>
>>>> If I understand your last few mails, you won't accept such driver, isn't it?
>>>
>>> You got wrong. You can't change someone's else license without their acks.
>>
>> That I understand very well. I never want to force anybody to change
>> his licence.
>>
>> I simply don't believe you that it is necessary. Why the same was not needed
>> with USBIP driver? If you check theirs nice big picture on
>> http://usbip.sourceforge.net/
>> you see that it is exactly same technology like vtunerc, but for USB subsystem.
>> Why such driver exists at all?
>>
>> And I'm sure I can find more examples inside kernel tree. What about NBD
>> (http://nbd.sourceforge.net)? Do you want find me more examples?
>>
>>> It is as simple as that. Getting everybody's ack is not that hard, if they
>>> accept that what you're doing is the right thing. We've got everybody's
>>> ack in the past to change the licensing for videodev2.h for example, to allow
>>> using the V4L2 API under BSD license (just the license API was changed, not the
>>> code itself).
>>>
>>>>> If people have different understandings, then we'll likely need to ask some
>>>>> support from Open source lawyers about this subject.
>>>>
>>>> My very little opinion is that waving GPL is way to the hell. Nobody told me
>>>> why similar technologies, in different kernel parts are acceptable,
>>>> but not here.
>>>
>>> If you want to do the networking code at userspace, why do you need a kernel
>>> driver after all? The proper solution is to write an userspace library for that,
>>> and either enclose such library inside the applications, or use LD_PRELOAD to
>>> bind the library to handle the open/close/ioctl glibc calls. libv4l does that.
>>> As it proofed to be a good library, now almost all V4L applications are using
>>> it.
>>
>> LD_PELOAD is out of bussiness for normal work. It is technique for development
>> and/or debugging.
> 
> Well, libv4l successfully uses LD_PRELOAD in order to support all applications 
> that weren't ported to it yet. It offers two ways:
> 	1) you can use it as a normal library;
> 	2) you can use it with LD_PRELOAD.
> 
> 
>> Library would be possible, but then you kill main advantage
>> - totally independece of changes inside userland DVB applications.
> 
> Why? if you write a "dvb_open", "dvb_ioctl", ... methods with the same syntax of
> glibc open, ioctl, ..., the efforts to migrate an userspace application to use it
> is to just run:
> 	sed s,open,dvb_open,g
> 	sed s,ioctl,dvb_ioctl,g
> 
> 
> The library and the application will be completely independent.

How do you transparently set up the network parameters? By using
environment variables? How do you pass existing sockets to the library?
How do you intercept an open() that won't ever happen, because no
virtual device to be opened exists?

> On the other hand, if you put it at kernelspace, you'll need to have an stable
> userspace API for every ioctl, as we don't allow userspace API breakages. So,
> new features will need to be backward compatible.

Not a big deal. We're quite experienced in it, aren't we?

Regards,
Andreas

Re: [RFC] vtunerc - virtual DVB device driver

[HoP]

2011/6/22 Mauro Carvalho Chehab <mchehab@redhat.com>:
> Em 22-06-2011 09:30, Andreas Oberritter escreveu:
>> On 06/22/2011 02:17 PM, Mauro Carvalho Chehab wrote:
>>> Em 21-06-2011 14:38, HoP escreveu:
>>>> 2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>>> Em 21-06-2011 12:09, Andreas Oberritter escreveu:
>>>>>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
>>>>>>> Em 21-06-2011 11:15, Andreas Oberritter escreveu:
>>>>>>>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
>>>>>>>>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
>>>>>>>>>> Mauro and Devin, I think you're missing the point. This is not about
>>>>>>>>>> creating drivers in userspace. This is not about open or closed source.
>>>>>>>>>> The "vtuner" interface, as implemented for the Dreambox, is used to
>>>>>>>>>> access remote tuners: Put x tuners into y boxes and access them from
>>>>>>>>>> another box as if they were local. It's used in conjunction with further
>>>>>>>>>> software to receive the transport stream over a network connection.
>>>>>>>>>> Honza's code does the same thing.
>>>>>>>>>
>>>>>>>>> I'm not missing the point at all.  I realize exactly what Honza is
>>>>>>>>> trying to accomplish (and from a purely technical standpoint, it's not
>>>>>>>>> a bad approach) - but I'm talking about the effects of such a driver
>>>>>>>>> being introduced which changes the kernel/userland licensing boundary
>>>>>>>>> and has very real implications with how the in-kernel code is
>>>>>>>>> accessed.
>>>>>>>>>
>>>>>>>>>> You don't need it in order to create closed source drivers. You can
>>>>>>>>>> already create closed kernel drivers now. Also, you can create tuner
>>>>>>>>>> drivers in userspace using the i2c-dev interface. If you like to connect
>>>>>>>>>> a userspace driver to a DVB API device node, you can distribute a small
>>>>>>>>>> (open or closed) wrapper with it. So what are you arguing about?
>>>>>>>>>> Everything you're feared of can already be done since virtually forever.
>>>>>>>>>
>>>>>>>>> I disagree.  There is currently no API which allows applications to
>>>>>>>>> issue tuning requests into the DVB core, and have those requests
>>>>>>>>> proxied back out to userland where an application can then use i2c-dev
>>>>>>>>> to tune the actual device.  Meaning if somebody wants to write a
>>>>>>>>> closed source userland application which controls the tuner, he/she
>>>>>>>>> can do that (while not conforming to the DVB API).  But if if he wants
>>>>>>>>> to reuse the GPL licensed DVB core, he has to replace the entire DVB
>>>>>>>>> core.
>>>>>>>>>
>>>>>>>>> The introduction of this patch makes it trivial for a third party to
>>>>>>>>> provide closed-source userland support for tuners while reusing all
>>>>>>>>> the existing GPL driver code that makes up the framework.
>>>>>>>>>
>>>>>>>>> I used to work for a vendor that makes tuners, and they do a bunch of
>>>>>>>>> Linux work.  And that work has resulted in a bunch of open source
>>>>>>>>> drivers.  I can tell you though that *every* conversation I've had
>>>>>>>>> regarding a new driver goes something like this:
>>>>>>>>>
>>>>>>>>> ===
>>>>>>>>> "Devin, we need to support tuner X under Linux."
>>>>>>>>>
>>>>>>>>> "Great!  I'll be happy to write a new GPL driver for the
>>>>>>>>> tuner/demodulator/whatever for that device"
>>>>>>>>>
>>>>>>>>> "But to save time/money, we just want to reuse the Windows driver code
>>>>>>>>> (or reference code from the vendor)."
>>>>>>>>>
>>>>>>>>> "Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"
>>>>>>>>>
>>>>>>>>> "Not currently.  So can we just make our driver closed source?"
>>>>>>>>>
>>>>>>>>> "Well, you can't reuse any of the existing DVB core functionality or
>>>>>>>>> any of the other GPL drivers (tuners, bridges, demods), so you would
>>>>>>>>> have rewrite all that from scratch."
>>>>>>>>>
>>>>>>>>> "Oh, that would be a ton of work.   Can we maybe write some userland
>>>>>>>>> stuff that controls the demodulator which we can keep closed source?
>>>>>>>>> Since it's not in the kernel, the GPL won't apply".
>>>>>>>>>
>>>>>>>>> "Well, you can't really do that because there is no way for the DVB
>>>>>>>>> core to call back out to userland when the application makes the
>>>>>>>>> tuning request to the DVB core."
>>>>>>>>>
>>>>>>>>> "Oh, ok then.  I guess we'll have to talk to the vendor and get them
>>>>>>>>> to give us the reference driver code under the GPL."
>>>>>>>>> ===
>>>>>>>>>
>>>>>>>>> I can tell you without a doubt that if this driver were present in the
>>>>>>>>> kernel, that going forward that vendor would have *zero* interest in
>>>>>>>>> doing any GPL driver work.  Why would they?  Why give away the code
>>>>>>>>> which could potentially help their competitors if they can keep it
>>>>>>>>> safe and protected while still being able to reuse everybody else's
>>>>>>>>> contributions?
>>>>>>>>>
>>>>>>>>> Companies don't contribute GPL code out of "good will".  They do it
>>>>>>>>> because they are compelled to by licenses or because there is no
>>>>>>>>> economically viable alternative.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> Anyway, I said in my last email that would be my last email on the
>>>>>>>>> topic.  I guess I lied.
>>>>>>>>
>>>>>>>> Yes, and you did lie to your vendor, too, as you did not mention the
>>>>>>>> possibilities to create
>>>>>>>> 1.) closed source modules derived from existing vendor drivers while
>>>>>>>> still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
>>>>>>>> EXPORT_SYMBOL_GPL).
>>>>>>>
>>>>>>> AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL
>>>>>>> are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly
>>>>>>> adds a restriction, not using it doesn't necessarily mean that the symbol
>>>>>>> can be used by a closed source driver.
>>>>>>>
>>>>>>> If you take a look at Kernel's COPYING file, the only exception to GPL license
>>>>>>> allowed there is:
>>>>>>>
>>>>>>>       NOTE! This copyright does *not* cover user programs that use kernel
>>>>>>>       services by normal system calls - this is merely considered normal use
>>>>>>>       of the kernel, and does *not* fall under the heading of "derived work".
>>>>>>>
>>>>>>> IANAL, but, as EXPORT_SYMBOL is not a "normal system call", my understanding is that
>>>>>>> it is also covered by GPL.
>>>>>>
>>>>>> Of course. But as you should know, the GPL only covers derived work.
>>>>>> Whether or not a driver is a derived work of the kernel can only be
>>>>>> decided individually. It is my understanding that a Windows driver
>>>>>> ported to Linux is unlikely to be a derived work of Linux.
>>>>>>
>>>>>>> I was told that several lawyers defend the idea that all software inside the
>>>>>>> kernel tree is covered by GPL, even the aggregated ones. That was the rationale
>>>>>>> used to split the firmware packages from the kernel itself.
>>>>>>
>>>>>> However, I wasn't referring to the kernel tree at all.
>>>>>>
>>>>>>>> 2.) a simple wrapper that calls userspace, therefore not having to open
>>>>>>>> up any "secrets" at all.
>>>>>>>
>>>>>>> A wrapper for a closed source driver is illegal, as it is trying to circumvent
>>>>>>> the GPL license.
>>>>>>
>>>>>> Is it? First, you are not a lawyer. Second, a wrapper is unlikely to be
>>>>>> illegal by its pure existence and a wrapper does usually not try to do
>>>>>> anything by itself. Third, you can implement a wrapper using normal
>>>>>> system calls (read, write, mmap, ioctl ...). That's what vtuner does,
>>>>>> too, to accomplish a totally different goal. Do you think vtuner is
>>>>>> illegal? I would be very surprised if it was. It perfectly matches the
>>>>>> license exception cited above. And even without the exception, a closed
>>>>>> driver in userspace would only very unlikely be a derived work of the
>>>>>> kernel.
>>>>>
>>>>> I think we're diverging from the subject. Most of those discussions are
>>>>> interesting on some lawyers forum, not here.
>>>>>
>>>>> My view about this subject is that vtuner can't give any additional permissions
>>>>> to the kernel GPL'd code, as vtuner were not made by the Kernel Copyright owners,
>>>>> nor were approved by them. So, the extra permission at the COPYING clause
>>>>> from kernel doesn't apply here, while the code is not merged into the Kernel.
>>>>>
>>>>> So, while it should be legal to use vtuner with a GPL'd client application,
>>>>> using it by a closed source application violates GPL.
>>>>>
>>>>> My understanding is that an addition of a code that exposes the internal
>>>>> DVB core API to userspace like that will require that all dvb developers
>>>>> that have copyright rights at the dvb core should explicitly ack with such
>>>>> change, otherwise adding such code will violate the original license.
>>>>>
>>>>> On the other hand, if vtunerc won't act as a proxy to userspace, it should
>>>>> probably be ok.
>>>>
>>>> Are you serious? Why there is not same violation on NFS? Or even beter
>>>> example NBD (network block device)? It sits in kernel for ages and nobody
>>>> cares. It looks for me like you should send some patch for removal such
>>>> "weak" places in kernel which allow to violate GPL.
>>>>
>>>> Do you really think that it is possible (in real, no in threory) to create
>>>> any networked subsystem for sharing anything over net the way
>>>> when it is not exposed (somehow) to the userspace? How will be
>>>> such system managable? Why there is usually companion daemon
>>>> there, which is responsible for managing connections etc?
>>>>
>>>> I think it is very evident you want find the way how to get yours word
>>>> back and return to your original position = such code is not acceptable.
>>>> Even if you still are not able to give anything clear.
>>>>
>>>> If I understand your last few mails, you won't accept such driver, isn't it?
>>>
>>> You got wrong. You can't change someone's else license without their acks.
>>> It is as simple as that. Getting everybody's ack is not that hard, if they
>>> accept that what you're doing is the right thing. We've got everybody's
>>> ack in the past to change the licensing for videodev2.h for example, to allow
>>> using the V4L2 API under BSD license (just the license API was changed, not the
>>> code itself).
>>
>> Is there anybode else who thinks that adding GPL'd code to the GPL'd
>> kernel would require any change in licensing? This is insane. What
>> change to whose license are you referring to, please?
>
> Kernel licensing is not a pure GPL license. If it were a pure GPL license, all software
> that would run on the top of it would need to also be released under GPL.
>
> Kernel license is GPLv2 + additional rights to allow binary code to run on the top
> of it, for the system calls that are introduced in order to allow the usage of
> the hardware resources managed by the Kernel (drivers, network, memory, CPU's, etc).
>
> There are no doubts that dvb developers wanted their drivers to be controlled from
> userspace, but, from previous discussions about this subject, several developers
> explicitly said that they didn't want to allow any kind of wrapper module to be added.

OK, if I even accede to your (rather strange) argument, then, staying strongly
on licencing rules - can you answer me if such "discussions" has any lawyer
base? I didn't see anything like "code is released under GPL2 with one exception
- no wrappers, please" in any commit. My really weak knowledge of GPL
make me wonder
if it is possible.

And of course - you wording about wrapper. Then every other
virtualization driver
can be named wrapper. But it is still driver, if you like it or nope.

/Honza

Re: [RFC] vtunerc - virtual DVB device driver

[Mauro Carvalho Chehab]

Em 22-06-2011 10:13, Andreas Oberritter escreveu:
> On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote:
>> Em 22-06-2011 09:37, HoP escreveu:
>>> 2011/6/22 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>> Em 21-06-2011 14:38, HoP escreveu:
>>>>> 2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>>>> Em 21-06-2011 12:09, Andreas Oberritter escreveu:
>>>>>>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
>>>>>>>> Em 21-06-2011 11:15, Andreas Oberritter escreveu:
>>>>>>>>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
>>>>>>>>>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
>>>>>>>>>>> Mauro and Devin, I think you're missing the point. This is not about
>>>>>>>>>>> creating drivers in userspace. This is not about open or closed source.
>>>>>>>>>>> The "vtuner" interface, as implemented for the Dreambox, is used to
>>>>>>>>>>> access remote tuners: Put x tuners into y boxes and access them from
>>>>>>>>>>> another box as if they were local. It's used in conjunction with further
>>>>>>>>>>> software to receive the transport stream over a network connection.
>>>>>>>>>>> Honza's code does the same thing.
>>>>>>>>>>
>>>>>>>>>> I'm not missing the point at all.  I realize exactly what Honza is
>>>>>>>>>> trying to accomplish (and from a purely technical standpoint, it's not
>>>>>>>>>> a bad approach) - but I'm talking about the effects of such a driver
>>>>>>>>>> being introduced which changes the kernel/userland licensing boundary
>>>>>>>>>> and has very real implications with how the in-kernel code is
>>>>>>>>>> accessed.
>>>>>>>>>>
>>>>>>>>>>> You don't need it in order to create closed source drivers. You can
>>>>>>>>>>> already create closed kernel drivers now. Also, you can create tuner
>>>>>>>>>>> drivers in userspace using the i2c-dev interface. If you like to connect
>>>>>>>>>>> a userspace driver to a DVB API device node, you can distribute a small
>>>>>>>>>>> (open or closed) wrapper with it. So what are you arguing about?
>>>>>>>>>>> Everything you're feared of can already be done since virtually forever.
>>>>>>>>>>
>>>>>>>>>> I disagree.  There is currently no API which allows applications to
>>>>>>>>>> issue tuning requests into the DVB core, and have those requests
>>>>>>>>>> proxied back out to userland where an application can then use i2c-dev
>>>>>>>>>> to tune the actual device.  Meaning if somebody wants to write a
>>>>>>>>>> closed source userland application which controls the tuner, he/she
>>>>>>>>>> can do that (while not conforming to the DVB API).  But if if he wants
>>>>>>>>>> to reuse the GPL licensed DVB core, he has to replace the entire DVB
>>>>>>>>>> core.
>>>>>>>>>>
>>>>>>>>>> The introduction of this patch makes it trivial for a third party to
>>>>>>>>>> provide closed-source userland support for tuners while reusing all
>>>>>>>>>> the existing GPL driver code that makes up the framework.
>>>>>>>>>>
>>>>>>>>>> I used to work for a vendor that makes tuners, and they do a bunch of
>>>>>>>>>> Linux work.  And that work has resulted in a bunch of open source
>>>>>>>>>> drivers.  I can tell you though that *every* conversation I've had
>>>>>>>>>> regarding a new driver goes something like this:
>>>>>>>>>>
>>>>>>>>>> ===
>>>>>>>>>> "Devin, we need to support tuner X under Linux."
>>>>>>>>>>
>>>>>>>>>> "Great!  I'll be happy to write a new GPL driver for the
>>>>>>>>>> tuner/demodulator/whatever for that device"
>>>>>>>>>>
>>>>>>>>>> "But to save time/money, we just want to reuse the Windows driver code
>>>>>>>>>> (or reference code from the vendor)."
>>>>>>>>>>
>>>>>>>>>> "Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"
>>>>>>>>>>
>>>>>>>>>> "Not currently.  So can we just make our driver closed source?"
>>>>>>>>>>
>>>>>>>>>> "Well, you can't reuse any of the existing DVB core functionality or
>>>>>>>>>> any of the other GPL drivers (tuners, bridges, demods), so you would
>>>>>>>>>> have rewrite all that from scratch."
>>>>>>>>>>
>>>>>>>>>> "Oh, that would be a ton of work.   Can we maybe write some userland
>>>>>>>>>> stuff that controls the demodulator which we can keep closed source?
>>>>>>>>>> Since it's not in the kernel, the GPL won't apply".
>>>>>>>>>>
>>>>>>>>>> "Well, you can't really do that because there is no way for the DVB
>>>>>>>>>> core to call back out to userland when the application makes the
>>>>>>>>>> tuning request to the DVB core."
>>>>>>>>>>
>>>>>>>>>> "Oh, ok then.  I guess we'll have to talk to the vendor and get them
>>>>>>>>>> to give us the reference driver code under the GPL."
>>>>>>>>>> ===
>>>>>>>>>>
>>>>>>>>>> I can tell you without a doubt that if this driver were present in the
>>>>>>>>>> kernel, that going forward that vendor would have *zero* interest in
>>>>>>>>>> doing any GPL driver work.  Why would they?  Why give away the code
>>>>>>>>>> which could potentially help their competitors if they can keep it
>>>>>>>>>> safe and protected while still being able to reuse everybody else's
>>>>>>>>>> contributions?
>>>>>>>>>>
>>>>>>>>>> Companies don't contribute GPL code out of "good will".  They do it
>>>>>>>>>> because they are compelled to by licenses or because there is no
>>>>>>>>>> economically viable alternative.
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> Anyway, I said in my last email that would be my last email on the
>>>>>>>>>> topic.  I guess I lied.
>>>>>>>>>
>>>>>>>>> Yes, and you did lie to your vendor, too, as you did not mention the
>>>>>>>>> possibilities to create
>>>>>>>>> 1.) closed source modules derived from existing vendor drivers while
>>>>>>>>> still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
>>>>>>>>> EXPORT_SYMBOL_GPL).
>>>>>>>>
>>>>>>>> AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL
>>>>>>>> are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly
>>>>>>>> adds a restriction, not using it doesn't necessarily mean that the symbol
>>>>>>>> can be used by a closed source driver.
>>>>>>>>
>>>>>>>> If you take a look at Kernel's COPYING file, the only exception to GPL license
>>>>>>>> allowed there is:
>>>>>>>>
>>>>>>>>       NOTE! This copyright does *not* cover user programs that use kernel
>>>>>>>>       services by normal system calls - this is merely considered normal use
>>>>>>>>       of the kernel, and does *not* fall under the heading of "derived work".
>>>>>>>>
>>>>>>>> IANAL, but, as EXPORT_SYMBOL is not a "normal system call", my understanding is that
>>>>>>>> it is also covered by GPL.
>>>>>>>
>>>>>>> Of course. But as you should know, the GPL only covers derived work.
>>>>>>> Whether or not a driver is a derived work of the kernel can only be
>>>>>>> decided individually. It is my understanding that a Windows driver
>>>>>>> ported to Linux is unlikely to be a derived work of Linux.
>>>>>>>
>>>>>>>> I was told that several lawyers defend the idea that all software inside the
>>>>>>>> kernel tree is covered by GPL, even the aggregated ones. That was the rationale
>>>>>>>> used to split the firmware packages from the kernel itself.
>>>>>>>
>>>>>>> However, I wasn't referring to the kernel tree at all.
>>>>>>>
>>>>>>>>> 2.) a simple wrapper that calls userspace, therefore not having to open
>>>>>>>>> up any "secrets" at all.
>>>>>>>>
>>>>>>>> A wrapper for a closed source driver is illegal, as it is trying to circumvent
>>>>>>>> the GPL license.
>>>>>>>
>>>>>>> Is it? First, you are not a lawyer. Second, a wrapper is unlikely to be
>>>>>>> illegal by its pure existence and a wrapper does usually not try to do
>>>>>>> anything by itself. Third, you can implement a wrapper using normal
>>>>>>> system calls (read, write, mmap, ioctl ...). That's what vtuner does,
>>>>>>> too, to accomplish a totally different goal. Do you think vtuner is
>>>>>>> illegal? I would be very surprised if it was. It perfectly matches the
>>>>>>> license exception cited above. And even without the exception, a closed
>>>>>>> driver in userspace would only very unlikely be a derived work of the
>>>>>>> kernel.
>>>>>>
>>>>>> I think we're diverging from the subject. Most of those discussions are
>>>>>> interesting on some lawyers forum, not here.
>>>>>>
>>>>>> My view about this subject is that vtuner can't give any additional permissions
>>>>>> to the kernel GPL'd code, as vtuner were not made by the Kernel Copyright owners,
>>>>>> nor were approved by them. So, the extra permission at the COPYING clause
>>>>>> from kernel doesn't apply here, while the code is not merged into the Kernel.
>>>>>>
>>>>>> So, while it should be legal to use vtuner with a GPL'd client application,
>>>>>> using it by a closed source application violates GPL.
>>>>>>
>>>>>> My understanding is that an addition of a code that exposes the internal
>>>>>> DVB core API to userspace like that will require that all dvb developers
>>>>>> that have copyright rights at the dvb core should explicitly ack with such
>>>>>> change, otherwise adding such code will violate the original license.
>>>>>>
>>>>>> On the other hand, if vtunerc won't act as a proxy to userspace, it should
>>>>>> probably be ok.
>>>>>
>>>>> Are you serious? Why there is not same violation on NFS? Or even beter
>>>>> example NBD (network block device)? It sits in kernel for ages and nobody
>>>>> cares. It looks for me like you should send some patch for removal such
>>>>> "weak" places in kernel which allow to violate GPL.
>>>>>
>>>>> Do you really think that it is possible (in real, no in threory) to create
>>>>> any networked subsystem for sharing anything over net the way
>>>>> when it is not exposed (somehow) to the userspace? How will be
>>>>> such system managable? Why there is usually companion daemon
>>>>> there, which is responsible for managing connections etc?
>>>>>
>>>>> I think it is very evident you want find the way how to get yours word
>>>>> back and return to your original position = such code is not acceptable.
>>>>> Even if you still are not able to give anything clear.
>>>>>
>>>>> If I understand your last few mails, you won't accept such driver, isn't it?
>>>>
>>>> You got wrong. You can't change someone's else license without their acks.
>>>
>>> That I understand very well. I never want to force anybody to change
>>> his licence.
>>>
>>> I simply don't believe you that it is necessary. Why the same was not needed
>>> with USBIP driver? If you check theirs nice big picture on
>>> http://usbip.sourceforge.net/
>>> you see that it is exactly same technology like vtunerc, but for USB subsystem.
>>> Why such driver exists at all?
>>>
>>> And I'm sure I can find more examples inside kernel tree. What about NBD
>>> (http://nbd.sourceforge.net)? Do you want find me more examples?
>>>
>>>> It is as simple as that. Getting everybody's ack is not that hard, if they
>>>> accept that what you're doing is the right thing. We've got everybody's
>>>> ack in the past to change the licensing for videodev2.h for example, to allow
>>>> using the V4L2 API under BSD license (just the license API was changed, not the
>>>> code itself).
>>>>
>>>>>> If people have different understandings, then we'll likely need to ask some
>>>>>> support from Open source lawyers about this subject.
>>>>>
>>>>> My very little opinion is that waving GPL is way to the hell. Nobody told me
>>>>> why similar technologies, in different kernel parts are acceptable,
>>>>> but not here.
>>>>
>>>> If you want to do the networking code at userspace, why do you need a kernel
>>>> driver after all? The proper solution is to write an userspace library for that,
>>>> and either enclose such library inside the applications, or use LD_PRELOAD to
>>>> bind the library to handle the open/close/ioctl glibc calls. libv4l does that.
>>>> As it proofed to be a good library, now almost all V4L applications are using
>>>> it.
>>>
>>> LD_PELOAD is out of bussiness for normal work. It is technique for development
>>> and/or debugging.
>>
>> Well, libv4l successfully uses LD_PRELOAD in order to support all applications 
>> that weren't ported to it yet. It offers two ways:
>> 	1) you can use it as a normal library;
>> 	2) you can use it with LD_PRELOAD.
>>
>>
>>> Library would be possible, but then you kill main advantage
>>> - totally independece of changes inside userland DVB applications.
>>
>> Why? if you write a "dvb_open", "dvb_ioctl", ... methods with the same syntax of
>> glibc open, ioctl, ..., the efforts to migrate an userspace application to use it
>> is to just run:
>> 	sed s,open,dvb_open,g
>> 	sed s,ioctl,dvb_ioctl,g
>>
>>
>> The library and the application will be completely independent.
> 
> How do you transparently set up the network parameters? By using
> environment variables? How do you pass existing sockets to the library?
> How do you intercept an open() that won't ever happen, because no
> virtual device to be opened exists?

Sorry, but I failed to see at the vtunerc driver anything network-related.
Also, the picture shows that it is just acting as a proxy to an userspace code
that it is actually handling the network conversion. The complete solution
seems to have a kernel driver and an userspace client/daemon.

Technically, doing such proxy in kernel is not a good idea, due to several
reasons:

1) The proxy code and the userspace network client will need to be tightly coupled:
if you add a new feature at the proxy, the same feature will need to be supported by
the userspace daemon;

2) Data will need to be using copy_from_user/copy_to_user for every data access;

3) There's no good reason to write such code inside kernelspace.

On a library based approach, what you'll have, instead is a library. The same
userspace client/daemon will be needed. However, as both can be shipped together
(the library proxy code and the userspace client/daemon), there are several
advantages, like:

1) The library and the userspace client will be in sync: there's no need to check
for version differences at the api, or providing any sort of backport support;

2) There's no need to recompile the kernel when someone wants to use the proxy;

3) The userspace won't be bound to the Kernel release schedule: When the code is
stable enough, both libraries and userspace can be released at the same time.

Mauro.

Re: [RFC] vtunerc - virtual DVB device driver

[HoP]

2011/6/22 Mauro Carvalho Chehab <mchehab@redhat.com>:
> Em 22-06-2011 10:13, Andreas Oberritter escreveu:
>> On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote:
>>> Em 22-06-2011 09:37, HoP escreveu:
>>>> 2011/6/22 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>>> Em 21-06-2011 14:38, HoP escreveu:
>>>>>> 2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>>>>> Em 21-06-2011 12:09, Andreas Oberritter escreveu:
>>>>>>>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
>>>>>>>>> Em 21-06-2011 11:15, Andreas Oberritter escreveu:
>>>>>>>>>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
>>>>>>>>>>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
>>>>>>>>>>>> Mauro and Devin, I think you're missing the point. This is not about
>>>>>>>>>>>> creating drivers in userspace. This is not about open or closed source.
>>>>>>>>>>>> The "vtuner" interface, as implemented for the Dreambox, is used to
>>>>>>>>>>>> access remote tuners: Put x tuners into y boxes and access them from
>>>>>>>>>>>> another box as if they were local. It's used in conjunction with further
>>>>>>>>>>>> software to receive the transport stream over a network connection.
>>>>>>>>>>>> Honza's code does the same thing.
>>>>>>>>>>>
>>>>>>>>>>> I'm not missing the point at all.  I realize exactly what Honza is
>>>>>>>>>>> trying to accomplish (and from a purely technical standpoint, it's not
>>>>>>>>>>> a bad approach) - but I'm talking about the effects of such a driver
>>>>>>>>>>> being introduced which changes the kernel/userland licensing boundary
>>>>>>>>>>> and has very real implications with how the in-kernel code is
>>>>>>>>>>> accessed.
>>>>>>>>>>>
>>>>>>>>>>>> You don't need it in order to create closed source drivers. You can
>>>>>>>>>>>> already create closed kernel drivers now. Also, you can create tuner
>>>>>>>>>>>> drivers in userspace using the i2c-dev interface. If you like to connect
>>>>>>>>>>>> a userspace driver to a DVB API device node, you can distribute a small
>>>>>>>>>>>> (open or closed) wrapper with it. So what are you arguing about?
>>>>>>>>>>>> Everything you're feared of can already be done since virtually forever.
>>>>>>>>>>>
>>>>>>>>>>> I disagree.  There is currently no API which allows applications to
>>>>>>>>>>> issue tuning requests into the DVB core, and have those requests
>>>>>>>>>>> proxied back out to userland where an application can then use i2c-dev
>>>>>>>>>>> to tune the actual device.  Meaning if somebody wants to write a
>>>>>>>>>>> closed source userland application which controls the tuner, he/she
>>>>>>>>>>> can do that (while not conforming to the DVB API).  But if if he wants
>>>>>>>>>>> to reuse the GPL licensed DVB core, he has to replace the entire DVB
>>>>>>>>>>> core.
>>>>>>>>>>>
>>>>>>>>>>> The introduction of this patch makes it trivial for a third party to
>>>>>>>>>>> provide closed-source userland support for tuners while reusing all
>>>>>>>>>>> the existing GPL driver code that makes up the framework.
>>>>>>>>>>>
>>>>>>>>>>> I used to work for a vendor that makes tuners, and they do a bunch of
>>>>>>>>>>> Linux work.  And that work has resulted in a bunch of open source
>>>>>>>>>>> drivers.  I can tell you though that *every* conversation I've had
>>>>>>>>>>> regarding a new driver goes something like this:
>>>>>>>>>>>
>>>>>>>>>>> ===
>>>>>>>>>>> "Devin, we need to support tuner X under Linux."
>>>>>>>>>>>
>>>>>>>>>>> "Great!  I'll be happy to write a new GPL driver for the
>>>>>>>>>>> tuner/demodulator/whatever for that device"
>>>>>>>>>>>
>>>>>>>>>>> "But to save time/money, we just want to reuse the Windows driver code
>>>>>>>>>>> (or reference code from the vendor)."
>>>>>>>>>>>
>>>>>>>>>>> "Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"
>>>>>>>>>>>
>>>>>>>>>>> "Not currently.  So can we just make our driver closed source?"
>>>>>>>>>>>
>>>>>>>>>>> "Well, you can't reuse any of the existing DVB core functionality or
>>>>>>>>>>> any of the other GPL drivers (tuners, bridges, demods), so you would
>>>>>>>>>>> have rewrite all that from scratch."
>>>>>>>>>>>
>>>>>>>>>>> "Oh, that would be a ton of work.   Can we maybe write some userland
>>>>>>>>>>> stuff that controls the demodulator which we can keep closed source?
>>>>>>>>>>> Since it's not in the kernel, the GPL won't apply".
>>>>>>>>>>>
>>>>>>>>>>> "Well, you can't really do that because there is no way for the DVB
>>>>>>>>>>> core to call back out to userland when the application makes the
>>>>>>>>>>> tuning request to the DVB core."
>>>>>>>>>>>
>>>>>>>>>>> "Oh, ok then.  I guess we'll have to talk to the vendor and get them
>>>>>>>>>>> to give us the reference driver code under the GPL."
>>>>>>>>>>> ===
>>>>>>>>>>>
>>>>>>>>>>> I can tell you without a doubt that if this driver were present in the
>>>>>>>>>>> kernel, that going forward that vendor would have *zero* interest in
>>>>>>>>>>> doing any GPL driver work.  Why would they?  Why give away the code
>>>>>>>>>>> which could potentially help their competitors if they can keep it
>>>>>>>>>>> safe and protected while still being able to reuse everybody else's
>>>>>>>>>>> contributions?
>>>>>>>>>>>
>>>>>>>>>>> Companies don't contribute GPL code out of "good will".  They do it
>>>>>>>>>>> because they are compelled to by licenses or because there is no
>>>>>>>>>>> economically viable alternative.
>>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> Anyway, I said in my last email that would be my last email on the
>>>>>>>>>>> topic.  I guess I lied.
>>>>>>>>>>
>>>>>>>>>> Yes, and you did lie to your vendor, too, as you did not mention the
>>>>>>>>>> possibilities to create
>>>>>>>>>> 1.) closed source modules derived from existing vendor drivers while
>>>>>>>>>> still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
>>>>>>>>>> EXPORT_SYMBOL_GPL).
>>>>>>>>>
>>>>>>>>> AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL
>>>>>>>>> are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly
>>>>>>>>> adds a restriction, not using it doesn't necessarily mean that the symbol
>>>>>>>>> can be used by a closed source driver.
>>>>>>>>>
>>>>>>>>> If you take a look at Kernel's COPYING file, the only exception to GPL license
>>>>>>>>> allowed there is:
>>>>>>>>>
>>>>>>>>>       NOTE! This copyright does *not* cover user programs that use kernel
>>>>>>>>>       services by normal system calls - this is merely considered normal use
>>>>>>>>>       of the kernel, and does *not* fall under the heading of "derived work".
>>>>>>>>>
>>>>>>>>> IANAL, but, as EXPORT_SYMBOL is not a "normal system call", my understanding is that
>>>>>>>>> it is also covered by GPL.
>>>>>>>>
>>>>>>>> Of course. But as you should know, the GPL only covers derived work.
>>>>>>>> Whether or not a driver is a derived work of the kernel can only be
>>>>>>>> decided individually. It is my understanding that a Windows driver
>>>>>>>> ported to Linux is unlikely to be a derived work of Linux.
>>>>>>>>
>>>>>>>>> I was told that several lawyers defend the idea that all software inside the
>>>>>>>>> kernel tree is covered by GPL, even the aggregated ones. That was the rationale
>>>>>>>>> used to split the firmware packages from the kernel itself.
>>>>>>>>
>>>>>>>> However, I wasn't referring to the kernel tree at all.
>>>>>>>>
>>>>>>>>>> 2.) a simple wrapper that calls userspace, therefore not having to open
>>>>>>>>>> up any "secrets" at all.
>>>>>>>>>
>>>>>>>>> A wrapper for a closed source driver is illegal, as it is trying to circumvent
>>>>>>>>> the GPL license.
>>>>>>>>
>>>>>>>> Is it? First, you are not a lawyer. Second, a wrapper is unlikely to be
>>>>>>>> illegal by its pure existence and a wrapper does usually not try to do
>>>>>>>> anything by itself. Third, you can implement a wrapper using normal
>>>>>>>> system calls (read, write, mmap, ioctl ...). That's what vtuner does,
>>>>>>>> too, to accomplish a totally different goal. Do you think vtuner is
>>>>>>>> illegal? I would be very surprised if it was. It perfectly matches the
>>>>>>>> license exception cited above. And even without the exception, a closed
>>>>>>>> driver in userspace would only very unlikely be a derived work of the
>>>>>>>> kernel.
>>>>>>>
>>>>>>> I think we're diverging from the subject. Most of those discussions are
>>>>>>> interesting on some lawyers forum, not here.
>>>>>>>
>>>>>>> My view about this subject is that vtuner can't give any additional permissions
>>>>>>> to the kernel GPL'd code, as vtuner were not made by the Kernel Copyright owners,
>>>>>>> nor were approved by them. So, the extra permission at the COPYING clause
>>>>>>> from kernel doesn't apply here, while the code is not merged into the Kernel.
>>>>>>>
>>>>>>> So, while it should be legal to use vtuner with a GPL'd client application,
>>>>>>> using it by a closed source application violates GPL.
>>>>>>>
>>>>>>> My understanding is that an addition of a code that exposes the internal
>>>>>>> DVB core API to userspace like that will require that all dvb developers
>>>>>>> that have copyright rights at the dvb core should explicitly ack with such
>>>>>>> change, otherwise adding such code will violate the original license.
>>>>>>>
>>>>>>> On the other hand, if vtunerc won't act as a proxy to userspace, it should
>>>>>>> probably be ok.
>>>>>>
>>>>>> Are you serious? Why there is not same violation on NFS? Or even beter
>>>>>> example NBD (network block device)? It sits in kernel for ages and nobody
>>>>>> cares. It looks for me like you should send some patch for removal such
>>>>>> "weak" places in kernel which allow to violate GPL.
>>>>>>
>>>>>> Do you really think that it is possible (in real, no in threory) to create
>>>>>> any networked subsystem for sharing anything over net the way
>>>>>> when it is not exposed (somehow) to the userspace? How will be
>>>>>> such system managable? Why there is usually companion daemon
>>>>>> there, which is responsible for managing connections etc?
>>>>>>
>>>>>> I think it is very evident you want find the way how to get yours word
>>>>>> back and return to your original position = such code is not acceptable.
>>>>>> Even if you still are not able to give anything clear.
>>>>>>
>>>>>> If I understand your last few mails, you won't accept such driver, isn't it?
>>>>>
>>>>> You got wrong. You can't change someone's else license without their acks.
>>>>
>>>> That I understand very well. I never want to force anybody to change
>>>> his licence.
>>>>
>>>> I simply don't believe you that it is necessary. Why the same was not needed
>>>> with USBIP driver? If you check theirs nice big picture on
>>>> http://usbip.sourceforge.net/
>>>> you see that it is exactly same technology like vtunerc, but for USB subsystem.
>>>> Why such driver exists at all?
>>>>
>>>> And I'm sure I can find more examples inside kernel tree. What about NBD
>>>> (http://nbd.sourceforge.net)? Do you want find me more examples?
>>>>
>>>>> It is as simple as that. Getting everybody's ack is not that hard, if they
>>>>> accept that what you're doing is the right thing. We've got everybody's
>>>>> ack in the past to change the licensing for videodev2.h for example, to allow
>>>>> using the V4L2 API under BSD license (just the license API was changed, not the
>>>>> code itself).
>>>>>
>>>>>>> If people have different understandings, then we'll likely need to ask some
>>>>>>> support from Open source lawyers about this subject.
>>>>>>
>>>>>> My very little opinion is that waving GPL is way to the hell. Nobody told me
>>>>>> why similar technologies, in different kernel parts are acceptable,
>>>>>> but not here.
>>>>>
>>>>> If you want to do the networking code at userspace, why do you need a kernel
>>>>> driver after all? The proper solution is to write an userspace library for that,
>>>>> and either enclose such library inside the applications, or use LD_PRELOAD to
>>>>> bind the library to handle the open/close/ioctl glibc calls. libv4l does that.
>>>>> As it proofed to be a good library, now almost all V4L applications are using
>>>>> it.
>>>>
>>>> LD_PELOAD is out of bussiness for normal work. It is technique for development
>>>> and/or debugging.
>>>
>>> Well, libv4l successfully uses LD_PRELOAD in order to support all applications
>>> that weren't ported to it yet. It offers two ways:
>>>      1) you can use it as a normal library;
>>>      2) you can use it with LD_PRELOAD.
>>>
>>>
>>>> Library would be possible, but then you kill main advantage
>>>> - totally independece of changes inside userland DVB applications.
>>>
>>> Why? if you write a "dvb_open", "dvb_ioctl", ... methods with the same syntax of
>>> glibc open, ioctl, ..., the efforts to migrate an userspace application to use it
>>> is to just run:
>>>      sed s,open,dvb_open,g
>>>      sed s,ioctl,dvb_ioctl,g
>>>
>>>
>>> The library and the application will be completely independent.
>>
>> How do you transparently set up the network parameters? By using
>> environment variables? How do you pass existing sockets to the library?
>> How do you intercept an open() that won't ever happen, because no
>> virtual device to be opened exists?
>
> Sorry, but I failed to see at the vtunerc driver anything network-related.
> Also, the picture shows that it is just acting as a proxy to an userspace code
> that it is actually handling the network conversion. The complete solution
> seems to have a kernel driver and an userspace client/daemon.
>
> Technically, doing such proxy in kernel is not a good idea, due to several
> reasons:
>
> 1) The proxy code and the userspace network client will need to be tightly coupled:
> if you add a new feature at the proxy, the same feature will need to be supported by
> the userspace daemon;
>
> 2) Data will need to be using copy_from_user/copy_to_user for every data access;
>
> 3) There's no good reason to write such code inside kernelspace.
>
> On a library based approach, what you'll have, instead is a library. The same
> userspace client/daemon will be needed. However, as both can be shipped together
> (the library proxy code and the userspace client/daemon), there are several
> advantages, like:
>
> 1) The library and the userspace client will be in sync: there's no need to check
> for version differences at the api, or providing any sort of backport support;
>
> 2) There's no need to recompile the kernel when someone wants to use the proxy;
>
> 3) The userspace won't be bound to the Kernel release schedule: When the code is
> stable enough, both libraries and userspace can be released at the same time.

If you are (for first time!) inside technical discussion, please
answer my already
asked questions why it is done in other kernel sybsystems and nobody
needs to complain against it. I can refresh you similarities I have found
already - USBIP (http://usbip.sourceforge.net/) and NBD
(http://nbd.sourceforge.net/)?

/Honza

Re: [RFC] vtunerc - virtual DVB device driver

[Mauro Carvalho Chehab]

Em 22-06-2011 11:03, HoP escreveu:
> 2011/6/22 Mauro Carvalho Chehab <mchehab@redhat.com>:
>> Em 22-06-2011 10:13, Andreas Oberritter escreveu:
>>> On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote:
>>>> Em 22-06-2011 09:37, HoP escreveu:
>>>>> 2011/6/22 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>>>> Em 21-06-2011 14:38, HoP escreveu:
>>>>>>> 2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>>>>>> Em 21-06-2011 12:09, Andreas Oberritter escreveu:
>>>>>>>>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote:
>>>>>>>>>> Em 21-06-2011 11:15, Andreas Oberritter escreveu:
>>>>>>>>>>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote:
>>>>>>>>>>>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter <obi@linuxtv.org> wrote:
>>>>>>>>>>>>> Mauro and Devin, I think you're missing the point. This is not about
>>>>>>>>>>>>> creating drivers in userspace. This is not about open or closed source.
>>>>>>>>>>>>> The "vtuner" interface, as implemented for the Dreambox, is used to
>>>>>>>>>>>>> access remote tuners: Put x tuners into y boxes and access them from
>>>>>>>>>>>>> another box as if they were local. It's used in conjunction with further
>>>>>>>>>>>>> software to receive the transport stream over a network connection.
>>>>>>>>>>>>> Honza's code does the same thing.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not missing the point at all.  I realize exactly what Honza is
>>>>>>>>>>>> trying to accomplish (and from a purely technical standpoint, it's not
>>>>>>>>>>>> a bad approach) - but I'm talking about the effects of such a driver
>>>>>>>>>>>> being introduced which changes the kernel/userland licensing boundary
>>>>>>>>>>>> and has very real implications with how the in-kernel code is
>>>>>>>>>>>> accessed.
>>>>>>>>>>>>
>>>>>>>>>>>>> You don't need it in order to create closed source drivers. You can
>>>>>>>>>>>>> already create closed kernel drivers now. Also, you can create tuner
>>>>>>>>>>>>> drivers in userspace using the i2c-dev interface. If you like to connect
>>>>>>>>>>>>> a userspace driver to a DVB API device node, you can distribute a small
>>>>>>>>>>>>> (open or closed) wrapper with it. So what are you arguing about?
>>>>>>>>>>>>> Everything you're feared of can already be done since virtually forever.
>>>>>>>>>>>>
>>>>>>>>>>>> I disagree.  There is currently no API which allows applications to
>>>>>>>>>>>> issue tuning requests into the DVB core, and have those requests
>>>>>>>>>>>> proxied back out to userland where an application can then use i2c-dev
>>>>>>>>>>>> to tune the actual device.  Meaning if somebody wants to write a
>>>>>>>>>>>> closed source userland application which controls the tuner, he/she
>>>>>>>>>>>> can do that (while not conforming to the DVB API).  But if if he wants
>>>>>>>>>>>> to reuse the GPL licensed DVB core, he has to replace the entire DVB
>>>>>>>>>>>> core.
>>>>>>>>>>>>
>>>>>>>>>>>> The introduction of this patch makes it trivial for a third party to
>>>>>>>>>>>> provide closed-source userland support for tuners while reusing all
>>>>>>>>>>>> the existing GPL driver code that makes up the framework.
>>>>>>>>>>>>
>>>>>>>>>>>> I used to work for a vendor that makes tuners, and they do a bunch of
>>>>>>>>>>>> Linux work.  And that work has resulted in a bunch of open source
>>>>>>>>>>>> drivers.  I can tell you though that *every* conversation I've had
>>>>>>>>>>>> regarding a new driver goes something like this:
>>>>>>>>>>>>
>>>>>>>>>>>> ===
>>>>>>>>>>>> "Devin, we need to support tuner X under Linux."
>>>>>>>>>>>>
>>>>>>>>>>>> "Great!  I'll be happy to write a new GPL driver for the
>>>>>>>>>>>> tuner/demodulator/whatever for that device"
>>>>>>>>>>>>
>>>>>>>>>>>> "But to save time/money, we just want to reuse the Windows driver code
>>>>>>>>>>>> (or reference code from the vendor)."
>>>>>>>>>>>>
>>>>>>>>>>>> "Ok.  Well, what is the licensing for that code?  Is it GPL compatible?"
>>>>>>>>>>>>
>>>>>>>>>>>> "Not currently.  So can we just make our driver closed source?"
>>>>>>>>>>>>
>>>>>>>>>>>> "Well, you can't reuse any of the existing DVB core functionality or
>>>>>>>>>>>> any of the other GPL drivers (tuners, bridges, demods), so you would
>>>>>>>>>>>> have rewrite all that from scratch."
>>>>>>>>>>>>
>>>>>>>>>>>> "Oh, that would be a ton of work.   Can we maybe write some userland
>>>>>>>>>>>> stuff that controls the demodulator which we can keep closed source?
>>>>>>>>>>>> Since it's not in the kernel, the GPL won't apply".
>>>>>>>>>>>>
>>>>>>>>>>>> "Well, you can't really do that because there is no way for the DVB
>>>>>>>>>>>> core to call back out to userland when the application makes the
>>>>>>>>>>>> tuning request to the DVB core."
>>>>>>>>>>>>
>>>>>>>>>>>> "Oh, ok then.  I guess we'll have to talk to the vendor and get them
>>>>>>>>>>>> to give us the reference driver code under the GPL."
>>>>>>>>>>>> ===
>>>>>>>>>>>>
>>>>>>>>>>>> I can tell you without a doubt that if this driver were present in the
>>>>>>>>>>>> kernel, that going forward that vendor would have *zero* interest in
>>>>>>>>>>>> doing any GPL driver work.  Why would they?  Why give away the code
>>>>>>>>>>>> which could potentially help their competitors if they can keep it
>>>>>>>>>>>> safe and protected while still being able to reuse everybody else's
>>>>>>>>>>>> contributions?
>>>>>>>>>>>>
>>>>>>>>>>>> Companies don't contribute GPL code out of "good will".  They do it
>>>>>>>>>>>> because they are compelled to by licenses or because there is no
>>>>>>>>>>>> economically viable alternative.
>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> Anyway, I said in my last email that would be my last email on the
>>>>>>>>>>>> topic.  I guess I lied.
>>>>>>>>>>>
>>>>>>>>>>> Yes, and you did lie to your vendor, too, as you did not mention the
>>>>>>>>>>> possibilities to create
>>>>>>>>>>> 1.) closed source modules derived from existing vendor drivers while
>>>>>>>>>>> still being able to use other drivers (c.f. EXPORT_SYMBOL vs.
>>>>>>>>>>> EXPORT_SYMBOL_GPL).
>>>>>>>>>>
>>>>>>>>>> AFAIK, the legal issues on writing a closed source driver using EXPORT_SYMBOL
>>>>>>>>>> are not proofed legally in any court. While EXPORT_SYMBOL_GPL explicitly
>>>>>>>>>> adds a restriction, not using it doesn't necessarily mean that the symbol
>>>>>>>>>> can be used by a closed source driver.
>>>>>>>>>>
>>>>>>>>>> If you take a look at Kernel's COPYING file, the only exception to GPL license
>>>>>>>>>> allowed there is:
>>>>>>>>>>
>>>>>>>>>>       NOTE! This copyright does *not* cover user programs that use kernel
>>>>>>>>>>       services by normal system calls - this is merely considered normal use
>>>>>>>>>>       of the kernel, and does *not* fall under the heading of "derived work".
>>>>>>>>>>
>>>>>>>>>> IANAL, but, as EXPORT_SYMBOL is not a "normal system call", my understanding is that
>>>>>>>>>> it is also covered by GPL.
>>>>>>>>>
>>>>>>>>> Of course. But as you should know, the GPL only covers derived work.
>>>>>>>>> Whether or not a driver is a derived work of the kernel can only be
>>>>>>>>> decided individually. It is my understanding that a Windows driver
>>>>>>>>> ported to Linux is unlikely to be a derived work of Linux.
>>>>>>>>>
>>>>>>>>>> I was told that several lawyers defend the idea that all software inside the
>>>>>>>>>> kernel tree is covered by GPL, even the aggregated ones. That was the rationale
>>>>>>>>>> used to split the firmware packages from the kernel itself.
>>>>>>>>>
>>>>>>>>> However, I wasn't referring to the kernel tree at all.
>>>>>>>>>
>>>>>>>>>>> 2.) a simple wrapper that calls userspace, therefore not having to open
>>>>>>>>>>> up any "secrets" at all.
>>>>>>>>>>
>>>>>>>>>> A wrapper for a closed source driver is illegal, as it is trying to circumvent
>>>>>>>>>> the GPL license.
>>>>>>>>>
>>>>>>>>> Is it? First, you are not a lawyer. Second, a wrapper is unlikely to be
>>>>>>>>> illegal by its pure existence and a wrapper does usually not try to do
>>>>>>>>> anything by itself. Third, you can implement a wrapper using normal
>>>>>>>>> system calls (read, write, mmap, ioctl ...). That's what vtuner does,
>>>>>>>>> too, to accomplish a totally different goal. Do you think vtuner is
>>>>>>>>> illegal? I would be very surprised if it was. It perfectly matches the
>>>>>>>>> license exception cited above. And even without the exception, a closed
>>>>>>>>> driver in userspace would only very unlikely be a derived work of the
>>>>>>>>> kernel.
>>>>>>>>
>>>>>>>> I think we're diverging from the subject. Most of those discussions are
>>>>>>>> interesting on some lawyers forum, not here.
>>>>>>>>
>>>>>>>> My view about this subject is that vtuner can't give any additional permissions
>>>>>>>> to the kernel GPL'd code, as vtuner were not made by the Kernel Copyright owners,
>>>>>>>> nor were approved by them. So, the extra permission at the COPYING clause
>>>>>>>> from kernel doesn't apply here, while the code is not merged into the Kernel.
>>>>>>>>
>>>>>>>> So, while it should be legal to use vtuner with a GPL'd client application,
>>>>>>>> using it by a closed source application violates GPL.
>>>>>>>>
>>>>>>>> My understanding is that an addition of a code that exposes the internal
>>>>>>>> DVB core API to userspace like that will require that all dvb developers
>>>>>>>> that have copyright rights at the dvb core should explicitly ack with such
>>>>>>>> change, otherwise adding such code will violate the original license.
>>>>>>>>
>>>>>>>> On the other hand, if vtunerc won't act as a proxy to userspace, it should
>>>>>>>> probably be ok.
>>>>>>>
>>>>>>> Are you serious? Why there is not same violation on NFS? Or even beter
>>>>>>> example NBD (network block device)? It sits in kernel for ages and nobody
>>>>>>> cares. It looks for me like you should send some patch for removal such
>>>>>>> "weak" places in kernel which allow to violate GPL.
>>>>>>>
>>>>>>> Do you really think that it is possible (in real, no in threory) to create
>>>>>>> any networked subsystem for sharing anything over net the way
>>>>>>> when it is not exposed (somehow) to the userspace? How will be
>>>>>>> such system managable? Why there is usually companion daemon
>>>>>>> there, which is responsible for managing connections etc?
>>>>>>>
>>>>>>> I think it is very evident you want find the way how to get yours word
>>>>>>> back and return to your original position = such code is not acceptable.
>>>>>>> Even if you still are not able to give anything clear.
>>>>>>>
>>>>>>> If I understand your last few mails, you won't accept such driver, isn't it?
>>>>>>
>>>>>> You got wrong. You can't change someone's else license without their acks.
>>>>>
>>>>> That I understand very well. I never want to force anybody to change
>>>>> his licence.
>>>>>
>>>>> I simply don't believe you that it is necessary. Why the same was not needed
>>>>> with USBIP driver? If you check theirs nice big picture on
>>>>> http://usbip.sourceforge.net/
>>>>> you see that it is exactly same technology like vtunerc, but for USB subsystem.
>>>>> Why such driver exists at all?
>>>>>
>>>>> And I'm sure I can find more examples inside kernel tree. What about NBD
>>>>> (http://nbd.sourceforge.net)? Do you want find me more examples?
>>>>>
>>>>>> It is as simple as that. Getting everybody's ack is not that hard, if they
>>>>>> accept that what you're doing is the right thing. We've got everybody's
>>>>>> ack in the past to change the licensing for videodev2.h for example, to allow
>>>>>> using the V4L2 API under BSD license (just the license API was changed, not the
>>>>>> code itself).
>>>>>>
>>>>>>>> If people have different understandings, then we'll likely need to ask some
>>>>>>>> support from Open source lawyers about this subject.
>>>>>>>
>>>>>>> My very little opinion is that waving GPL is way to the hell. Nobody told me
>>>>>>> why similar technologies, in different kernel parts are acceptable,
>>>>>>> but not here.
>>>>>>
>>>>>> If you want to do the networking code at userspace, why do you need a kernel
>>>>>> driver after all? The proper solution is to write an userspace library for that,
>>>>>> and either enclose such library inside the applications, or use LD_PRELOAD to
>>>>>> bind the library to handle the open/close/ioctl glibc calls. libv4l does that.
>>>>>> As it proofed to be a good library, now almost all V4L applications are using
>>>>>> it.
>>>>>
>>>>> LD_PELOAD is out of bussiness for normal work. It is technique for development
>>>>> and/or debugging.
>>>>
>>>> Well, libv4l successfully uses LD_PRELOAD in order to support all applications
>>>> that weren't ported to it yet. It offers two ways:
>>>>      1) you can use it as a normal library;
>>>>      2) you can use it with LD_PRELOAD.
>>>>
>>>>
>>>>> Library would be possible, but then you kill main advantage
>>>>> - totally independece of changes inside userland DVB applications.
>>>>
>>>> Why? if you write a "dvb_open", "dvb_ioctl", ... methods with the same syntax of
>>>> glibc open, ioctl, ..., the efforts to migrate an userspace application to use it
>>>> is to just run:
>>>>      sed s,open,dvb_open,g
>>>>      sed s,ioctl,dvb_ioctl,g
>>>>
>>>>
>>>> The library and the application will be completely independent.
>>>
>>> How do you transparently set up the network parameters? By using
>>> environment variables? How do you pass existing sockets to the library?
>>> How do you intercept an open() that won't ever happen, because no
>>> virtual device to be opened exists?
>>
>> Sorry, but I failed to see at the vtunerc driver anything network-related.
>> Also, the picture shows that it is just acting as a proxy to an userspace code
>> that it is actually handling the network conversion. The complete solution
>> seems to have a kernel driver and an userspace client/daemon.
>>
>> Technically, doing such proxy in kernel is not a good idea, due to several
>> reasons:
>>
>> 1) The proxy code and the userspace network client will need to be tightly coupled:
>> if you add a new feature at the proxy, the same feature will need to be supported by
>> the userspace daemon;
>>
>> 2) Data will need to be using copy_from_user/copy_to_user for every data access;
>>
>> 3) There's no good reason to write such code inside kernelspace.
>>
>> On a library based approach, what you'll have, instead is a library. The same
>> userspace client/daemon will be needed. However, as both can be shipped together
>> (the library proxy code and the userspace client/daemon), there are several
>> advantages, like:
>>
>> 1) The library and the userspace client will be in sync: there's no need to check
>> for version differences at the api, or providing any sort of backport support;
>>
>> 2) There's no need to recompile the kernel when someone wants to use the proxy;
>>
>> 3) The userspace won't be bound to the Kernel release schedule: When the code is
>> stable enough, both libraries and userspace can be released at the same time.
> 
> If you are (for first time!) inside technical discussion, please
> answer my already
> asked questions why it is done in other kernel sybsystems and nobody
> needs to complain against it. I can refresh you similarities I have found
> already - USBIP (http://usbip.sourceforge.net/) and NBD
> (http://nbd.sourceforge.net/)?

Currently, I can't tell you anything about those two projects, as I'm not aware of them.
I'll seek for some time to take a look on them.

Mauro

Re: [RFC] vtunerc - virtual DVB device driver

[Andreas Oberritter]

On 06/22/2011 03:45 PM, Mauro Carvalho Chehab wrote:
> Em 22-06-2011 10:13, Andreas Oberritter escreveu:
>> On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote:
>>> Em 22-06-2011 09:37, HoP escreveu:
>>>> 2011/6/22 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>>> Em 21-06-2011 14:38, HoP escreveu:
>>>>>> 2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
[...]
>>>>>>> If people have different understandings, then we'll likely need to ask some
>>>>>>> support from Open source lawyers about this subject.
>>>>>>
>>>>>> My very little opinion is that waving GPL is way to the hell. Nobody told me
>>>>>> why similar technologies, in different kernel parts are acceptable,
>>>>>> but not here.
>>>>>
>>>>> If you want to do the networking code at userspace, why do you need a kernel
>>>>> driver after all? The proper solution is to write an userspace library for that,
>>>>> and either enclose such library inside the applications, or use LD_PRELOAD to
>>>>> bind the library to handle the open/close/ioctl glibc calls. libv4l does that.
>>>>> As it proofed to be a good library, now almost all V4L applications are using
>>>>> it.
>>>>
>>>> LD_PELOAD is out of bussiness for normal work. It is technique for development
>>>> and/or debugging.
>>>
>>> Well, libv4l successfully uses LD_PRELOAD in order to support all applications 
>>> that weren't ported to it yet. It offers two ways:
>>> 	1) you can use it as a normal library;
>>> 	2) you can use it with LD_PRELOAD.
>>>
>>>
>>>> Library would be possible, but then you kill main advantage
>>>> - totally independece of changes inside userland DVB applications.
>>>
>>> Why? if you write a "dvb_open", "dvb_ioctl", ... methods with the same syntax of
>>> glibc open, ioctl, ..., the efforts to migrate an userspace application to use it
>>> is to just run:
>>> 	sed s,open,dvb_open,g
>>> 	sed s,ioctl,dvb_ioctl,g
>>>
>>>
>>> The library and the application will be completely independent.
>>
>> How do you transparently set up the network parameters? By using
>> environment variables? How do you pass existing sockets to the library?
>> How do you intercept an open() that won't ever happen, because no
>> virtual device to be opened exists?
> 
> Sorry, but I failed to see at the vtunerc driver anything network-related.

Of course it doesn't. You're the one who proposed to put networking into
the driver. I however fail to see how you imagined to add remote tuner
support to any existing application by using LD_PRELOAD.

> Also, the picture shows that it is just acting as a proxy to an userspace code
> that it is actually handling the network conversion. The complete solution
> seems to have a kernel driver and an userspace client/daemon.

Right.

> Technically, doing such proxy in kernel is not a good idea, due to several
> reasons:
> 
> 1) The proxy code and the userspace network client will need to be tightly coupled:
> if you add a new feature at the proxy, the same feature will need to be supported by
> the userspace daemon;

Just like anything else DVB related inside the kernel.

Adding a new feature to the proxy would mean that a new feature got
added to the frontend API, so a new kernel would be required anyway.

> 2) Data will need to be using copy_from_user/copy_to_user for every data access;

Also, just like anything else DVB related inside the kernel.

No one would notice some frontend ioctl parameters being copied twice.
We're talking about a few bytes.

Passing the remote TS to the kernel is completely *optional*, and only
required if you want to use the kernel's demux or the underlying
hardware's filtering and decoding features. However, the TS even gets
filtered before being transferred over the network. So again, even if
used though being optional, this is not a big data rate.

> 3) There's no good reason to write such code inside kernelspace.
> 
> On a library based approach, what you'll have, instead is a library. The same
> userspace client/daemon will be needed. However, as both can be shipped together
> (the library proxy code and the userspace client/daemon), there are several
> advantages, like:
> 
> 1) The library and the userspace client will be in sync: there's no need to check
> for version differences at the api, or providing any sort of backport support;

Breaking the ABI of libraries isn't much better than breaking the ABI of
kernel interfaces. A library may have many users, more than "the
userspace client" you're talking about.

> 2) There's no need to recompile the kernel when someone wants to use the proxy;

You could of course build it as a module, without the need to recompile
the kernel.

> 3) The userspace won't be bound to the Kernel release schedule: When the code is
> stable enough, both libraries and userspace can be released at the same time.

For the same reason one could argue that putting device drivers into
userspace would have the same benefits.

Well, the original proposal was to add a driver with supporting programs
which enables every existing DVB application to *transparently* work
with remote tuners.

What you're proposing now is to write a library, which works with remote
tuners, too, but which requires manual integration into each and every
application.

By the way, if we had such a library, supported by every major
application, then it would be very easy to implement closed source
frontend drivers on top of it. ;-)

Regards,
Andreas

Re: [RFC] vtunerc - virtual DVB device driver

[Mauro Carvalho Chehab]

Em 22-06-2011 11:24, Andreas Oberritter escreveu:
> On 06/22/2011 03:45 PM, Mauro Carvalho Chehab wrote:
>> Em 22-06-2011 10:13, Andreas Oberritter escreveu:
>>> On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote:
>>>> Em 22-06-2011 09:37, HoP escreveu:
>>>>> 2011/6/22 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>>>> Em 21-06-2011 14:38, HoP escreveu:
>>>>>>> 2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
> [...]
>>>>>>>> If people have different understandings, then we'll likely need to ask some
>>>>>>>> support from Open source lawyers about this subject.
>>>>>>>
>>>>>>> My very little opinion is that waving GPL is way to the hell. Nobody told me
>>>>>>> why similar technologies, in different kernel parts are acceptable,
>>>>>>> but not here.
>>>>>>
>>>>>> If you want to do the networking code at userspace, why do you need a kernel
>>>>>> driver after all? The proper solution is to write an userspace library for that,
>>>>>> and either enclose such library inside the applications, or use LD_PRELOAD to
>>>>>> bind the library to handle the open/close/ioctl glibc calls. libv4l does that.
>>>>>> As it proofed to be a good library, now almost all V4L applications are using
>>>>>> it.
>>>>>
>>>>> LD_PELOAD is out of bussiness for normal work. It is technique for development
>>>>> and/or debugging.
>>>>
>>>> Well, libv4l successfully uses LD_PRELOAD in order to support all applications 
>>>> that weren't ported to it yet. It offers two ways:
>>>> 	1) you can use it as a normal library;
>>>> 	2) you can use it with LD_PRELOAD.
>>>>
>>>>
>>>>> Library would be possible, but then you kill main advantage
>>>>> - totally independece of changes inside userland DVB applications.
>>>>
>>>> Why? if you write a "dvb_open", "dvb_ioctl", ... methods with the same syntax of
>>>> glibc open, ioctl, ..., the efforts to migrate an userspace application to use it
>>>> is to just run:
>>>> 	sed s,open,dvb_open,g
>>>> 	sed s,ioctl,dvb_ioctl,g
>>>>
>>>>
>>>> The library and the application will be completely independent.
>>>
>>> How do you transparently set up the network parameters? By using
>>> environment variables? How do you pass existing sockets to the library?
>>> How do you intercept an open() that won't ever happen, because no
>>> virtual device to be opened exists?
>>
>> Sorry, but I failed to see at the vtunerc driver anything network-related.
> 
> Of course it doesn't. You're the one who proposed to put networking into
> the driver. I however fail to see how you imagined to add remote tuner
> support to any existing application by using LD_PRELOAD.

If you take a look at libv4l, it hooks calls to open/close/ioctl/read/write glibc
calls. So, when an userspace application calls "open", it will run the library
code, and not glibc open function. So, it is completely transparent to the
userspace application.

>> Also, the picture shows that it is just acting as a proxy to an userspace code
>> that it is actually handling the network conversion. The complete solution
>> seems to have a kernel driver and an userspace client/daemon.
> 
> Right.
> 
>> Technically, doing such proxy in kernel is not a good idea, due to several
>> reasons:
>>
>> 1) The proxy code and the userspace network client will need to be tightly coupled:
>> if you add a new feature at the proxy, the same feature will need to be supported by
>> the userspace daemon;
> 
> Just like anything else DVB related inside the kernel.

Yes.

> Adding a new feature to the proxy would mean that a new feature got
> added to the frontend API, so a new kernel would be required anyway.
> 
>> 2) Data will need to be using copy_from_user/copy_to_user for every data access;
> 
> Also, just like anything else DVB related inside the kernel.

Yes, but if you do it on userspace, you don't need to do double buffering.
With a proxy, the same data will need to be passed 3 times from/to kernelspace:
2 times at vtunerc, and 1 time to the network driver. If implemented on userspace,
all it needed is to pass the data to the network driver, reducing latency.

Also, newer functions can be added on userspace in order to optimize applications
that will use it as a library, like providing functions that combine DVB and
network commands altogether.

> No one would notice some frontend ioctl parameters being copied twice.
> We're talking about a few bytes.

If the intention is to limit it to just frontend ioctl's, you're right: the
only difference is that latency will be a little higher, probably unnoticed
(yet, introduced for not a good reason). But, if the intention is to also
provide remote streaming, then the volume of data copied tree times will
be noticeable, especially if the stream is in HD and/or if support for full-featured
DVB cards is added later.

> Passing the remote TS to the kernel is completely *optional*, and only
> required if you want to use the kernel's demux or the underlying
> hardware's filtering and decoding features. However, the TS even gets
> filtered before being transferred over the network. So again, even if
> used though being optional, this is not a big data rate.
> 
>> 3) There's no good reason to write such code inside kernelspace.
>>
>> On a library based approach, what you'll have, instead is a library. The same
>> userspace client/daemon will be needed. However, as both can be shipped together
>> (the library proxy code and the userspace client/daemon), there are several
>> advantages, like:
>>
>> 1) The library and the userspace client will be in sync: there's no need to check
>> for version differences at the api, or providing any sort of backport support;
> 
> Breaking the ABI of libraries isn't much better than breaking the ABI of
> kernel interfaces. A library may have many users, more than "the
> userspace client" you're talking about.

That's partially true. If the library and the userspace client are bound together,
if new features are added at the library, the userspace client can assume that those
new features will be there. So, you only need to take care with backward compatibility
at the library side. With that functionality in Kernel, backward compatibility should 
be warranted on both ways.

>> 2) There's no need to recompile the kernel when someone wants to use the proxy;
> 
> You could of course build it as a module, without the need to recompile
> the kernel.

Yes. 

>> 3) The userspace won't be bound to the Kernel release schedule: When the code is
>> stable enough, both libraries and userspace can be released at the same time.
> 
> For the same reason one could argue that putting device drivers into
> userspace would have the same benefits.
> 
> Well, the original proposal was to add a driver with supporting programs
> which enables every existing DVB application to *transparently* work
> with remote tuners.
> 
> What you're proposing now is to write a library, which works with remote
> tuners, too, but which requires manual integration into each and every
> application.

With LD_PRELOAD, it will be transparent.

> By the way, if we had such a library, supported by every major
> application, then it would be very easy to implement closed source
> frontend drivers on top of it. ;-)

True.

Cheers,
Mauro

Re: [RFC] vtunerc - virtual DVB device driver

[Andreas Oberritter]

On 06/22/2011 05:19 PM, Mauro Carvalho Chehab wrote:
> Em 22-06-2011 11:24, Andreas Oberritter escreveu:
>> On 06/22/2011 03:45 PM, Mauro Carvalho Chehab wrote:
>>> Em 22-06-2011 10:13, Andreas Oberritter escreveu:
>>>> On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote:
>>>>> Em 22-06-2011 09:37, HoP escreveu:
>>>>>> 2011/6/22 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>>>>>> Em 21-06-2011 14:38, HoP escreveu:
>>>>>>>> 2011/6/21 Mauro Carvalho Chehab <mchehab@redhat.com>:
>> [...]
>>>>>>>>> If people have different understandings, then we'll likely need to ask some
>>>>>>>>> support from Open source lawyers about this subject.
>>>>>>>>
>>>>>>>> My very little opinion is that waving GPL is way to the hell. Nobody told me
>>>>>>>> why similar technologies, in different kernel parts are acceptable,
>>>>>>>> but not here.
>>>>>>>
>>>>>>> If you want to do the networking code at userspace, why do you need a kernel
>>>>>>> driver after all? The proper solution is to write an userspace library for that,
>>>>>>> and either enclose such library inside the applications, or use LD_PRELOAD to
>>>>>>> bind the library to handle the open/close/ioctl glibc calls. libv4l does that.
>>>>>>> As it proofed to be a good library, now almost all V4L applications are using
>>>>>>> it.
>>>>>>
>>>>>> LD_PELOAD is out of bussiness for normal work. It is technique for development
>>>>>> and/or debugging.
>>>>>
>>>>> Well, libv4l successfully uses LD_PRELOAD in order to support all applications 
>>>>> that weren't ported to it yet. It offers two ways:
>>>>> 	1) you can use it as a normal library;
>>>>> 	2) you can use it with LD_PRELOAD.
>>>>>
>>>>>
>>>>>> Library would be possible, but then you kill main advantage
>>>>>> - totally independece of changes inside userland DVB applications.
>>>>>
>>>>> Why? if you write a "dvb_open", "dvb_ioctl", ... methods with the same syntax of
>>>>> glibc open, ioctl, ..., the efforts to migrate an userspace application to use it
>>>>> is to just run:
>>>>> 	sed s,open,dvb_open,g
>>>>> 	sed s,ioctl,dvb_ioctl,g
>>>>>
>>>>>
>>>>> The library and the application will be completely independent.
>>>>
>>>> How do you transparently set up the network parameters? By using
>>>> environment variables? How do you pass existing sockets to the library?
>>>> How do you intercept an open() that won't ever happen, because no
>>>> virtual device to be opened exists?
>>>
>>> Sorry, but I failed to see at the vtunerc driver anything network-related.
>>
>> Of course it doesn't. You're the one who proposed to put networking into
>> the driver. I however fail to see how you imagined to add remote tuner
>> support to any existing application by using LD_PRELOAD.
> 
> If you take a look at libv4l, it hooks calls to open/close/ioctl/read/write glibc
> calls. So, when an userspace application calls "open", it will run the library
> code, and not glibc open function. So, it is completely transparent to the
> userspace application.

Again, please answer this question, how do you plan to intercept an
open() call for a character device that *doesn't exist*, because it's on
a remote system? That open() will never happen. LD_PRELOAD may have
worked well for whatever was needed for libv4l, but that's obviously a
different thing.

>>> Also, the picture shows that it is just acting as a proxy to an userspace code
>>> that it is actually handling the network conversion. The complete solution
>>> seems to have a kernel driver and an userspace client/daemon.
>>
>> Right.
>>
>>> Technically, doing such proxy in kernel is not a good idea, due to several
>>> reasons:
>>>
>>> 1) The proxy code and the userspace network client will need to be tightly coupled:
>>> if you add a new feature at the proxy, the same feature will need to be supported by
>>> the userspace daemon;
>>
>> Just like anything else DVB related inside the kernel.
> 
> Yes.
> 
>> Adding a new feature to the proxy would mean that a new feature got
>> added to the frontend API, so a new kernel would be required anyway.
>>
>>> 2) Data will need to be using copy_from_user/copy_to_user for every data access;
>>
>> Also, just like anything else DVB related inside the kernel.
> 
> Yes, but if you do it on userspace, you don't need to do double buffering.
> With a proxy, the same data will need to be passed 3 times from/to kernelspace:
> 2 times at vtunerc, and 1 time to the network driver. If implemented on userspace,
> all it needed is to pass the data to the network driver, reducing latency.
> 
> Also, newer functions can be added on userspace in order to optimize applications
> that will use it as a library, like providing functions that combine DVB and
> network commands altogether.
> 
>> No one would notice some frontend ioctl parameters being copied twice.
>> We're talking about a few bytes.
> 
> If the intention is to limit it to just frontend ioctl's, you're right: the
> only difference is that latency will be a little higher, probably unnoticed
> (yet, introduced for not a good reason). But, if the intention is to also
> provide remote streaming, then the volume of data copied tree times will
> be noticeable, especially if the stream is in HD and/or if support for full-featured
> DVB cards is added later.

Didn't you read the following paragraph? Yes, it's basically just
frontend ioctls. Transparency is a good reason in my opinion.

>> Passing the remote TS to the kernel is completely *optional*, and only
>> required if you want to use the kernel's demux or the underlying
>> hardware's filtering and decoding features. However, the TS even gets
>> filtered before being transferred over the network. So again, even if
>> used though being optional, this is not a big data rate.

If you want to decode a stream with a full featured card, you have to
copy it to kernel space *once*, not twice. This is optional.

If you want to use the kernel demux, you have to copy it to kernel space
once and partially copy back again, but filtered. Again, this is optional.

If you don't want to use the kernel demux and you don't want to use a
full featured card's decoder, there's no reason to copy anything to
kernel space at all.

You cannot avoid any of those copies by your library approach.

>>> 3) There's no good reason to write such code inside kernelspace.
>>>
>>> On a library based approach, what you'll have, instead is a library. The same
>>> userspace client/daemon will be needed. However, as both can be shipped together
>>> (the library proxy code and the userspace client/daemon), there are several
>>> advantages, like:
>>>
>>> 1) The library and the userspace client will be in sync: there's no need to check
>>> for version differences at the api, or providing any sort of backport support;
>>
>> Breaking the ABI of libraries isn't much better than breaking the ABI of
>> kernel interfaces. A library may have many users, more than "the
>> userspace client" you're talking about.
> 
> That's partially true. If the library and the userspace client are bound together,
> if new features are added at the library, the userspace client can assume that those
> new features will be there. So, you only need to take care with backward compatibility
> at the library side. With that functionality in Kernel, backward compatibility should 
> be warranted on both ways.
> 
>>> 2) There's no need to recompile the kernel when someone wants to use the proxy;
>>
>> You could of course build it as a module, without the need to recompile
>> the kernel.
> 
> Yes. 
> 
>>> 3) The userspace won't be bound to the Kernel release schedule: When the code is
>>> stable enough, both libraries and userspace can be released at the same time.
>>
>> For the same reason one could argue that putting device drivers into
>> userspace would have the same benefits.
>>
>> Well, the original proposal was to add a driver with supporting programs
>> which enables every existing DVB application to *transparently* work
>> with remote tuners.
>>
>> What you're proposing now is to write a library, which works with remote
>> tuners, too, but which requires manual integration into each and every
>> application.
> 
> With LD_PRELOAD, it will be transparent.

... but won't work.

>> By the way, if we had such a library, supported by every major
>> application, then it would be very easy to implement closed source
>> frontend drivers on top of it. ;-)
> 
> True.
> 
> Cheers,
> Mauro

Re: [RFC] vtunerc - virtual DVB device driver

[Steven Toth]

>> This is not a political issue. It is a licensing issue. If you want to use
>> someone's else code, you need to accept the licensing terms that the developers
>> are giving you, by either paying the price for the code usage (on closed source
>> licensing models), or by accepting the license when using an open-sourced code.

Mauro,

My comments for your review:

I've spoken on this topic many times, it's bad news for the LinuxTV
eco-system and it will eventually lead to binary only drivers that
ultimately diminishes all of the good work that me any my fellow
developers have poured into Linux over the last 5-10 years.

I repeat my message from 2 years ago when the subject was raised: and
this is (paraphrase) "I can say with great certainty that if we allow
API's that permit closed source drivers then silicon vendors and board
manufacturers will take advantage of that, they will only delivery (at
best) closed source drivers".

If closed source drivers is what the community wants then this is a
way to achieve this.

I don't want to see user-space drivers happen through LinuxDVB or V4L2 API's.

I politely and respectfully nack this idea.

Best,

- Steve

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: [RFC] vtunerc - virtual DVB device driver

[Michael Krufky]

On Sat, Jun 18, 2011 at 8:10 PM, HoP <jpetrous@gmail.com> wrote:
> Hi,
>
> get inspired by (unfortunately close-source) solution on stb
> Dreambox 800 I have made my own implementation
> of virtual DVB device, based on the same device API.
>
> In conjunction with "Dreamtuner" userland project
> [http://code.google.com/p/dreamtuner/] by Ronald Mieslinger
> user can create virtual DVB device on client side and connect it
> to the server. When connected, user is able to use any Linux DVB API
> compatible application on client side (like VDR, MeTV, MythTV, etc)
> without any need of code modification. As server can be used any
> Linux DVB API compatible device.


I can think of many interesting uses for a solution like this.  It's
great that such a driver exists and that people can use it now to
create interesting do-it-yourself projects, however, I do not believe
this should ever be merged into the kernel.

If this solution were merged into the kernel, there would be no reason
for companies like Hauppauge to ever again contribute any open source
drivers.  Once it's possible to deliver a closed source driver to the
masses, that's what vendors will do -- there will no longer be any
motivation to continue working in open source.

Some may like that idea, but I feel this will destroy the foundation
that we've been building for years.

I repeat, the solution itself has some potential, and I see nothing
wrong with this existing and being available to users in source code
form, but it should never be merged into a kernel to be shipped
directly to end-users.  This can create a horrible president that
would truly result in the prevention of open source driver
contributions from silicon vendors and hardware manufacturers.

Regards,

Michael Krufky
LinuxTV developer / Hauppauge Digital

Re: [RFC] vtunerc - virtual DVB device driver

[Rémi Denis-Courmont]

Le mercredi 22 juin 2011 15:17:27 Mauro Carvalho Chehab, vous avez écrit :
> > My very little opinion is that waving GPL is way to the hell. Nobody told
> > me why similar technologies, in different kernel parts are acceptable,
> > but not here.
> 
> If you want to do the networking code at userspace, why do you need a
> kernel driver after all?

Are you seriously asking why people write tunneling drivers in user-space? Or 
why they want to use the kernel-space socket API and protocol stack?

> The proper solution is to write an userspace
> library for that, and either enclose such library inside the applications,
> or use LD_PRELOAD to bind the library to handle the open/close/ioctl glibc
> calls. libv4l does that. As it proofed to be a good library, now almost
> all V4L applications are using it.

No. Set aside the problem of licensing, the correct way is to reuse existing 
code, which means the layer-3/4 stacks and the socket API in net/*. That 
avoids duplicating efforts (and bugs) and allows socket API apps to run 
unchanged and without brittle hacks like LD_PRELOAD.

And indeed, that's what the Linux ecosystem does, thanks to the tuntap network 
device driver.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis

Re: [RFC] vtunerc - virtual DVB device driver

[Mauro Carvalho Chehab]

Em 22-06-2011 16:18, Rémi Denis-Courmont escreveu:
> Le mercredi 22 juin 2011 15:17:27 Mauro Carvalho Chehab, vous avez écrit :
>>> My very little opinion is that waving GPL is way to the hell. Nobody told
>>> me why similar technologies, in different kernel parts are acceptable,
>>> but not here.
>>
>> If you want to do the networking code at userspace, why do you need a
>> kernel driver after all?
> 
> Are you seriously asking why people write tunneling drivers in user-space? Or 
> why they want to use the kernel-space socket API and protocol stack?
> 
>> The proper solution is to write an userspace
>> library for that, and either enclose such library inside the applications,
>> or use LD_PRELOAD to bind the library to handle the open/close/ioctl glibc
>> calls. libv4l does that. As it proofed to be a good library, now almost
>> all V4L applications are using it.
> 
> No. Set aside the problem of licensing, the correct way is to reuse existing 
> code, which means the layer-3/4 stacks and the socket API in net/*. That 
> avoids duplicating efforts (and bugs) and allows socket API apps to run 
> unchanged and without brittle hacks like LD_PRELOAD.
> 
> And indeed, that's what the Linux ecosystem does, thanks to the tuntap network 
> device driver.

Rémi,

Using the Kernel network layer is the right thing to do, but you don't need to add
a new driver for it: it is already there. All that userspace needs to do is to use
glibc socket's support.

It could make sense to have some sort of virtualization driver that would allow 
passing DVB API calls via, for example, the network socket API, to allow accessing
a physical DVB driver (or a remote machine DVB driver)from a VM machine. That was 
my original understanding.

Instead, the proposal is wrapper, that will be a sort of kernelspace implementation for
"LD_PRELOAD" that just returns the DVB commands back to some other application
in userspace. The real code to transmit DVB commands will be in userspace.

Technically speaking, this is a hack.

If I would code something like that, I would write it as a library with some functions like:
	connect_to_dvb()
	get_dvb_properties()
	get_frontend_parameters()
	set_frontend_parameters()
	get_dvb_ts()
And write a few patches for the userspace applications I would care.

If I wanted to provide transparent access to it, I would simply implement a LD_PRELOAD
schema, in order to help the new library deployment.

With such approach, at the initial stages (the worse case, e. g. using LD_PRELOAD), it will
be equivalent to have a kernel wrapper code, but, at long term, it will allow important
optimizations, like avoiding the need of copying data from/to the wrapper, supporting the extra
delays introducing by the network and allowing the applications to implement themselves the
dialog windows to control the network properties.

Thanks,
Mauro.