[patch 00/04] RFC: Staging tree (drivers/staging)

[patch 00/04] RFC: Staging tree (drivers/staging)

[Greg KH]

As we all discussed at the Kernel Summit this past week, I said I would
create a drivers/staging directory and start throwing lots of drivers
that are not of "mergable" status into it.

For those not at the kernel summit, lwn.net has a summary of this
session at:
	http://www.lwn.net/Articles/298570/

So, here's 4 patches for review/comments that show how this could be
done.

The first 2 patches create a TAINT_CRAP flag and set it for anything
that comes from the drivers/staging/ directory.  When a driver from this
directory is loaded into the kernel, the user is warned, and any oops
message that happens also properly shows the "bad" modules.

The 3rd patch creates the drivers/staging/ directory and Kconfig entries
and adds it to the build system.

The 4th patch is an example of a driver that would go into this
directory, along with a driver_name.README file detailing what needs to
be done to this driver for cleanup/fixing, and who to contact about it.
It's also in such bad shape it doesn't even build against the kernel
kernel :)

(I'll fix that up before submitting, all drivers should at least build
properly...)

So, does this all look good to everyone?  Any questions/issues?

Oh, I guess I should add a MAINTAINER entry for this section of the
kernel, so to paraphrase Linus, I now get to be known as the "Maintainer
of Crap".

thanks,

greg k-h

[patch 01/04] Staging: add TAINT_CRAP for all drivers/staging code

[Greg KH]

[-- Attachment #1: staging-add-taint_crap-for-all-drivers-staging-code.patch --]
[-- Type: text/plain, Size: 3314 bytes --]

We need to add a flag for all code that is in the drivers/staging/
directory to prevent all other kernel developers from worrying about
issues here, and to notify users that the drivers might not be as good
as they are normally used to.

Based on code from Andreas Gruenbacher and Jeff Mahoney to provide a
TAINT flag for the support level of a kernel module in the Novell
enterprise kernel release.

This is the kernel portion of this feature, the ability for the flag to
be set needs to be done in the build process and will happen in a
follow-up patch.

Cc: Andreas Gruenbacher <agruen@suse.de>
Cc: Jeff Mahoney <jeffm@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---

 Documentation/sysctl/kernel.txt |    1 +
 include/linux/kernel.h          |    1 +
 kernel/module.c                 |    9 +++++++++
 kernel/panic.c                  |    6 ++++--
 4 files changed, 15 insertions(+), 2 deletions(-)

--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -368,4 +368,5 @@ can be ORed together:
   2 - A module was force loaded by insmod -f.
       Set by modutils >= 2.4.9 and module-init-tools.
   4 - Unsafe SMP processors: SMP with CPUs not designed for SMP.
+ 64 - A module from drivers/staging was loaded.
 
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -261,6 +261,7 @@ extern enum system_states {
 #define TAINT_DIE			(1<<7)
 #define TAINT_OVERRIDDEN_ACPI_TABLE	(1<<8)
 #define TAINT_WARN			(1<<9)
+#define TAINT_CRAP			(1<<10)
 
 extern void dump_stack(void) __cold;
 
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1834,6 +1834,7 @@ static noinline struct module *load_modu
 	Elf_Ehdr *hdr;
 	Elf_Shdr *sechdrs;
 	char *secstrings, *args, *modmagic, *strtab = NULL;
+	char *staging;
 	unsigned int i;
 	unsigned int symindex = 0;
 	unsigned int strindex = 0;
@@ -1989,6 +1990,14 @@ static noinline struct module *load_modu
 		goto free_hdr;
 	}
 
+	staging = get_modinfo(sechdrs, infoindex, "staging");
+	if (staging) {
+		add_taint_module(mod, TAINT_CRAP);
+		printk(KERN_WARNING "%s: module is from the staging directory,"
+		       " the quality is unknown, you have been warned.\n",
+		       mod->name);
+	}
+
 	/* Now copy in args */
 	args = strndup_user(uargs, ~0UL >> 1);
 	if (IS_ERR(args)) {
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -155,6 +155,7 @@ EXPORT_SYMBOL(panic);
  *  'U' - Userspace-defined naughtiness.
  *  'A' - ACPI table overridden.
  *  'W' - Taint on warning.
+ *  'C' - modules from drivers/staging are loaded.
  *
  *	The string is overwritten by the next call to print_taint().
  */
@@ -163,7 +164,7 @@ const char *print_tainted(void)
 {
 	static char buf[20];
 	if (tainted) {
-		snprintf(buf, sizeof(buf), "Tainted: %c%c%c%c%c%c%c%c%c%c",
+		snprintf(buf, sizeof(buf), "Tainted: %c%c%c%c%c%c%c%c%c%c%c",
 			tainted & TAINT_PROPRIETARY_MODULE ? 'P' : 'G',
 			tainted & TAINT_FORCED_MODULE ? 'F' : ' ',
 			tainted & TAINT_UNSAFE_SMP ? 'S' : ' ',
@@ -173,7 +174,8 @@ const char *print_tainted(void)
 			tainted & TAINT_USER ? 'U' : ' ',
 			tainted & TAINT_DIE ? 'D' : ' ',
 			tainted & TAINT_OVERRIDDEN_ACPI_TABLE ? 'A' : ' ',
-			tainted & TAINT_WARN ? 'W' : ' ');
+			tainted & TAINT_WARN ? 'W' : ' ',
+			tainted & TAINT_CRAP ? 'C' : ' ');
 	}
 	else
 		snprintf(buf, sizeof(buf), "Not tainted");

-- 

[patch 02/04] Staging: add TAINT_CRAP flag to drivers/staging modules

[Greg KH]

[-- Attachment #1: staging-add-taint_crap-flag-to-drivers-staging-modules.patch --]
[-- Type: text/plain, Size: 1403 bytes --]

We need to add a flag for all code that is in the drivers/staging/
directory to prevent all other kernel developers from worrying about
issues here, and to notify users that the drivers might not be as good
as they are normally used to.

Based on code from Andreas Gruenbacher and Jeff Mahoney to provide a
TAINT flag for the support level of a kernel module in the Novell
enterprise kernel release.

This is the code that actually modifies the modules, adding the flag to
any files in the drivers/staging directory.

Cc: Andreas Gruenbacher <agruen@suse.de>
Cc: Jeff Mahoney <jeffm@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---

 scripts/mod/modpost.c |    9 +++++++++
 1 file changed, 9 insertions(+)

--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1726,6 +1726,14 @@ static void add_header(struct buffer *b,
 	buf_printf(b, "};\n");
 }
 
+void add_staging_flag(struct buffer *b, const char *name)
+{
+	static const char *staging_dir = "drivers/staging";
+
+	if (strncmp(staging_dir, name, strlen(staging_dir)) == 0)
+		buf_printf(b, "\nMODULE_INFO(staging, \"Y\");\n");
+}
+
 /**
  * Record CRCs for unresolved symbols
  **/
@@ -2133,6 +2141,7 @@ int main(int argc, char **argv)
 		buf.pos = 0;
 
 		add_header(&buf, mod);
+		add_staging_flag(&buf, mod->name);
 		err |= add_versions(&buf, mod);
 		add_depends(&buf, mod, modules);
 		add_moddevtable(&buf, mod);

-- 

[patch 04/04] USB: add princeton instruments usb camera driver

[Greg KH]

[-- Attachment #1: usb-add-princeton-instruments-usb-camera-driver.patch --]
[-- Type: text/plain, Size: 30936 bytes --]

Adds the driver for the Princeton Instruments USB camera.

Needs a lot of work...

TODO:
	- make checkpatch.pl clean
	- coding style fixups (typedefs, etc.)
	- get it to build properly
	- audit ioctls
	- remove ioctls if possible
	- assign proper minor number
	- remove dbg() macro
	- lots of general cleanups
	- review locking

Cc: Judd Montgomery <judd@jpilot.org>
Cc: Jeff Frontz <jeff.frontz@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/staging/Kconfig        |    5 
 drivers/staging/Makefile       |    1 
 drivers/staging/rspiusb.README |   22 +
 drivers/staging/rspiusb.c      |  887 +++++++++++++++++++++++++++++++++++++++++
 drivers/staging/rspiusb.h      |   25 +
 5 files changed, 940 insertions(+)

--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -23,5 +23,10 @@ menuconfig STAGING
 
 if STAGING
 
+config USB_RSPI
+	tristate "Princeton Instruments USB camera support"
+	depends on USB
+	help
+	  This driver is for the Princeton Instruments USB camera device.
 
 endif # STAGING
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -1,2 +1,3 @@
 # Makefile for staging directory
 
+obj-$(CONFIG_USB_RSPI)		+= rspiusb.o
--- /dev/null
+++ b/drivers/staging/rspiusb.c
@@ -0,0 +1,887 @@
+/*
+ * rspiusb.c
+ *
+ * Copyright (C) 2005, 2006 Princeton Instruments
+ *
+ * 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 of the License
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/vmalloc.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/smp_lock.h>
+#include <linux/completion.h>
+#include <linux/scatterlist.h>
+#include <linux/usb.h>
+#include <linux/mm.h>
+#include <linux/pagemap.h>
+#include <linux/ioctl.h>
+#include "rspiusb.h"
+
+#ifdef CONFIG_USB_DEBUG
+static int debug = 1;
+#else
+static int debug;
+#endif
+/* Use our own dbg macro */
+#undef dbg
+#define dbg(format, arg...) do { if (debug) printk(KERN_DEBUG __FILE__ ": " format "\n" , ## arg); } while (0)
+
+/* Version Information */
+#define DRIVER_VERSION "V1.0.1"
+#define DRIVER_AUTHOR  "Princeton Instruments"
+#define DRIVER_DESC    "PI USB2.0 Device Driver for Linux"
+
+/* Define these values to match your devices */
+#define VENDOR_ID   0x0BD7
+#define ST133_PID   0xA010
+#define PIXIS_PID   0xA026
+
+/* Get a minor range for your devices from the usb maintainer */
+#ifdef CONFIG_USB_DYNAMIC_MINORS
+#define PIUSB_MINOR_BASE    0
+#else
+#define PIUSB_MINOR_BASE    192
+#endif
+
+/* prevent races between open() and disconnect() */
+static DECLARE_MUTEX(disconnect_sem);
+
+/* Structure to hold all of our device specific stuff */
+struct device_extension {
+	struct usb_device *udev;	/* save off the usb device pointer */
+	struct usb_interface *interface;	/* the interface for this device */
+	unsigned char minor;	/* the starting minor number for this device */
+	size_t bulk_in_size_returned;
+	int bulk_in_byte_trk;
+	struct urb ***PixelUrb;
+	int frameIdx;
+	int urbIdx;
+	unsigned int *maplist_numPagesMapped;
+	int open;		/* if the port is open or not */
+	int present;		/* if the device is not disconnected */
+	int userBufMapped;	/* has the user buffer been mapped? */
+	struct scatterlist **sgl;	/* scatter-gather list for user buffer */
+	unsigned int *sgEntries;
+	struct kref kref;
+	int gotPixelData;
+	int pendingWrite;
+	char **pendedPixelUrbs;
+	int iama;		/*PIXIS or ST133 */
+	int num_frames;		/* the number of frames that will fit in the user buffer */
+	int active_frame;
+	unsigned long frameSize;
+	struct semaphore sem;
+	//FX2 specific endpoints
+	unsigned int hEP[8];
+};
+#define to_pi_dev(d) container_of( d, struct device_extension, kref )
+
+static int MapUserBuffer(struct ioctl_struct *, struct device_extension *);
+static int UnMapUserBuffer(struct device_extension *);
+static int piusb_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
+		       unsigned long arg);
+static int piusb_output(struct ioctl_struct *, unsigned char *, int, struct device_extension *);
+static struct usb_driver piusb_driver;
+
+/* table of devices that work with this driver */
+static struct usb_device_id pi_device_table[] = {
+	{USB_DEVICE(VENDOR_ID, ST133_PID)},
+	{USB_DEVICE(VENDOR_ID, PIXIS_PID)},
+	{0, }			/* Terminating entry */
+};
+
+MODULE_DEVICE_TABLE(usb, pi_device_table);
+
+static int lastErr = 0;
+static int errCnt = 0;
+
+static void piusb_delete(struct kref *kref)
+{
+	struct device_extension *pdx = to_pi_dev(kref);
+
+	dev_dbg(&pdx->udev->dev, "%s\n", __func__);
+	usb_put_dev(pdx->udev);
+	kfree(pdx);
+}
+
+static int piusb_open(struct inode *inode, struct file *file)
+{
+	struct device_extension *pdx = NULL;
+	struct usb_interface *interface;
+	int subminor;
+	int retval = 0;
+
+	dbg("Piusb_Open()");
+	subminor = iminor(inode);
+	interface = usb_find_interface(&piusb_driver, subminor);
+	if (!interface) {
+		printk(KERN_ERR "%s - error, can't find device for minor %d\n",
+		       __func__, subminor);
+		retval = -ENODEV;
+		goto exit_no_device;
+	}
+
+	pdx = usb_get_intfdata(interface);
+	if (!pdx) {
+		retval = -ENODEV;
+		goto exit_no_device;
+	}
+	dbg("Alternate Setting = %d", interface->num_altsetting);
+
+	pdx->frameIdx = pdx->urbIdx = 0;
+	pdx->gotPixelData = 0;
+	pdx->pendingWrite = 0;
+	pdx->frameSize = 0;
+	pdx->num_frames = 0;
+	pdx->active_frame = 0;
+	pdx->bulk_in_byte_trk = 0;
+	pdx->userBufMapped = 0;
+	pdx->pendedPixelUrbs = NULL;
+	pdx->sgEntries = NULL;
+	pdx->sgl = NULL;
+	pdx->maplist_numPagesMapped = NULL;
+	pdx->PixelUrb = NULL;
+	pdx->bulk_in_size_returned = 0;
+	/* increment our usage count for the device */
+	kref_get(&pdx->kref);
+	/* save our object in the file's private structure */
+	file->private_data = pdx;
+      exit_no_device:
+	return retval;
+}
+
+static int piusb_release(struct inode *inode, struct file *file)
+{
+	struct device_extension *pdx;
+	int retval = 0;
+
+	dbg("Piusb_Release()");
+	pdx = (struct device_extension *)file->private_data;
+	if (pdx == NULL) {
+		dbg("%s - object is NULL", __func__);
+		return -ENODEV;
+	}
+	/* decrement the count on our device */
+	kref_put(&pdx->kref, piusb_delete);
+	return retval;
+}
+
+/**
+ *	piusb_ioctl
+ */
+static int piusb_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
+		       unsigned long arg)
+{
+	struct device_extension *pdx;
+	char dummyCtlBuf[] = { 0, 0, 0, 0, 0, 0, 0, 0 };
+	unsigned long devRB = 0;
+	int i = 0;
+	int err = 0;
+	int retval = 0;
+	struct ioctl_struct ctrl;
+	unsigned char *uBuf;
+	int numbytes = 0;
+	unsigned short controlData = 0;
+
+	pdx = (struct device_extension *)file->private_data;
+	/* verify that the device wasn't unplugged */
+	if (!pdx->present) {
+		dbg("No Device Present\n");
+		return -ENODEV;
+	}
+	/* fill in your device specific stuff here */
+	if (_IOC_DIR(cmd) & _IOC_READ)
+		err = !access_ok(VERIFY_WRITE, (void __user *)arg, _IOC_SIZE(cmd));
+	else if (_IOC_DIR(cmd) & _IOC_WRITE)
+		err = !access_ok(VERIFY_READ, (void __user *)arg, _IOC_SIZE(cmd));
+	if (err) {
+		dev_err(&pdx->udev->dev, "return with error = %d\n", err);
+		return -EFAULT;
+	}
+	switch (cmd) {
+	case PIUSB_GETVNDCMD:
+		if (copy_from_user
+		    (&ctrl, (void __user *)arg, sizeof(struct ioctl_struct)))
+			info("copy_from_user failed\n");
+		dbg("%s %x\n", "Get Vendor Command = ", ctrl.cmd);
+		retval =
+		    usb_control_msg(pdx->udev, usb_rcvctrlpipe(pdx->udev, 0),
+				    ctrl.cmd, USB_DIR_IN, 0, 0, &devRB,
+				    ctrl.numbytes, HZ * 10);
+		if (ctrl.cmd == 0xF1) {
+			dbg("FW Version returned from HW = %ld.%ld",
+			    (devRB >> 8), (devRB & 0xFF));
+		}
+		return devRB;
+	case PIUSB_SETVNDCMD:
+		if (copy_from_user
+		    (&ctrl, (void __user *)arg, sizeof(struct ioctl_struct)))
+			info("copy_from_user failed\n");
+//            dbg( "%s %x", "Set Vendor Command = ",ctrl.cmd );
+		controlData = ctrl.pData[0];
+		controlData |= (ctrl.pData[1] << 8);
+//            dbg( "%s %d", "Vendor Data =",controlData );
+		retval = usb_control_msg(pdx->udev, usb_sndctrlpipe(pdx->udev, 0), ctrl.cmd, (USB_DIR_OUT | USB_TYPE_VENDOR),	/* | USB_RECIP_ENDPOINT), */
+					 controlData,
+					 0,
+					 &dummyCtlBuf, ctrl.numbytes, HZ * 10);
+		return retval;
+		break;
+	case PIUSB_ISHIGHSPEED:
+		return ((pdx->udev->speed == USB_SPEED_HIGH) ? 1 : 0);
+		break;
+	case PIUSB_WRITEPIPE:
+		if (copy_from_user(&ctrl, (void __user *)arg, _IOC_SIZE(cmd)))
+			info("copy_from_user WRITE_DUMMY failed\n");
+		if (!access_ok(VERIFY_READ, ctrl.pData, ctrl.numbytes)) {
+			dbg("can't access pData");
+			return 0;
+		}
+		piusb_output(&ctrl, ctrl.pData /*uBuf */ , ctrl.numbytes, pdx);
+		return ctrl.numbytes;
+		break;
+	case PIUSB_USERBUFFER:
+		if (copy_from_user
+		    (&ctrl, (void __user *)arg, sizeof(struct ioctl_struct)))
+			info("copy_from_user failed\n");
+		return MapUserBuffer((struct ioctl_struct *) & ctrl, pdx);
+		break;
+	case PIUSB_UNMAP_USERBUFFER:
+		UnMapUserBuffer(pdx);
+		return 0;
+		break;
+	case PIUSB_READPIPE:
+		if (copy_from_user
+		    (&ctrl, (void __user *)arg, sizeof(struct ioctl_struct)))
+			info("copy_from_user failed\n");
+		switch (ctrl.endpoint) {
+		case 0:	//ST133 Pixel Data or PIXIS IO
+			if (pdx->iama == PIXIS_PID) {
+				unsigned int numToRead = 0;
+				unsigned int totalRead = 0;
+				uBuf = kmalloc(ctrl.numbytes, GFP_KERNEL);
+				if (!uBuf) {
+					dbg("Alloc for uBuf failed");
+					return 0;
+				}
+				numbytes = ctrl.numbytes;
+				numToRead = numbytes;
+				dbg("numbytes to read = %d", numbytes);
+				dbg("endpoint # %d", ctrl.endpoint);
+				if (copy_from_user(uBuf, ctrl.pData, numbytes))
+					dbg("copying ctrl.pData to dummyBuf failed");
+				do {
+					i = usb_bulk_msg(pdx->udev, pdx->hEP[ctrl.endpoint], (uBuf + totalRead), (numToRead > 64) ? 64 : numToRead, &numbytes, HZ * 10);	//EP0 can only handle 64 bytes at a time
+					if (i) {
+						dbg("CMD = %s, Address = 0x%02X", ((uBuf[3] == 0x02) ? "WRITE" : "READ"), uBuf[1]);
+						dbg("Number of bytes Attempted to read = %d", (int)ctrl.numbytes);
+						dbg("Blocking ReadI/O Failed with status %d", i);
+						kfree(uBuf);
+						return -1;
+					} else {
+						dbg("Pixis EP0 Read %d bytes",
+						    numbytes);
+						totalRead += numbytes;
+						numToRead -= numbytes;
+					}
+				}
+				while (numToRead);
+				memcpy(ctrl.pData, uBuf, totalRead);
+				dbg("Total Bytes Read from PIXIS EP0 = %d",
+				    totalRead);
+				ctrl.numbytes = totalRead;
+				if (copy_to_user
+				    ((struct ioctl_struct *) arg, &ctrl,
+				     sizeof(struct ioctl_struct)))
+					dbg("copy_to_user failed in IORB");
+				kfree(uBuf);
+				return ctrl.numbytes;
+			} else	//ST133 Pixel Data
+			{
+				if (!pdx->gotPixelData)
+					return 0;
+				else {
+					pdx->gotPixelData = 0;
+					ctrl.numbytes =
+					    pdx->bulk_in_size_returned;
+					pdx->bulk_in_size_returned -=
+					    pdx->frameSize;
+					for (i = 0; i < pdx->maplist_numPagesMapped[pdx->active_frame]; i++)
+						SetPageDirty(pdx->sgl[pdx->active_frame][i].page_link);
+					pdx->active_frame =
+					    ((pdx->active_frame +
+					      1) % pdx->num_frames);
+					return ctrl.numbytes;
+				}
+			}
+			break;
+		case 1:	//ST133IO
+		case 4:	//PIXIS IO
+			uBuf = kmalloc(ctrl.numbytes, GFP_KERNEL);
+			if (!uBuf) {
+				dbg("Alloc for uBuf failed");
+				return 0;
+			}
+			numbytes = ctrl.numbytes;
+//                                      dbg( "numbytes to read = %d", numbytes );
+			if (copy_from_user(uBuf, ctrl.pData, numbytes))
+				dbg("copying ctrl.pData to dummyBuf failed");
+			i = usb_bulk_msg(pdx->udev, pdx->hEP[ctrl.endpoint],
+					 uBuf, numbytes, &numbytes, HZ * 10);
+			if (i) {
+				dbg("Blocking ReadI/O Failed with status %d",
+				    i);
+				kfree(uBuf);
+				return -1;
+			} else {
+				ctrl.numbytes = numbytes;
+				memcpy(ctrl.pData, uBuf, numbytes);
+				if (copy_to_user
+				    ((struct ioctl_struct *) arg, &ctrl,
+				     sizeof(struct ioctl_struct)))
+					dbg("copy_to_user failed in IORB");
+				kfree(uBuf);
+				return ctrl.numbytes;
+			}
+			break;
+
+		case 2:	//PIXIS Ping
+		case 3:	//PIXIS Pong
+			if (!pdx->gotPixelData)
+				return 0;
+			else {
+				pdx->gotPixelData = 0;
+				ctrl.numbytes = pdx->bulk_in_size_returned;
+				pdx->bulk_in_size_returned -= pdx->frameSize;
+				for (i = 0;
+				     i <
+				     pdx->maplist_numPagesMapped[pdx->
+								 active_frame];
+				     i++)
+					SetPageDirty(pdx->sgl[pdx->active_frame][i].page_link);
+				pdx->active_frame =
+				    ((pdx->active_frame + 1) % pdx->num_frames);
+				return ctrl.numbytes;
+			}
+			break;
+		}
+		break;
+	case PIUSB_WHATCAMERA:
+		return pdx->iama;
+	case PIUSB_SETFRAMESIZE:
+		dbg("PIUSB_SETFRAMESIZE");
+		if (copy_from_user
+		    (&ctrl, (void __user *)arg, sizeof(struct ioctl_struct)))
+			info("copy_from_user failed\n");
+		pdx->frameSize = ctrl.numbytes;
+		pdx->num_frames = ctrl.numFrames;
+		if (!pdx->sgl)
+			pdx->sgl =
+			    kmalloc(sizeof(struct scatterlist *) *
+				    pdx->num_frames, GFP_KERNEL);
+		if (!pdx->sgEntries)
+			pdx->sgEntries =
+			    kmalloc(sizeof(unsigned int) * pdx->num_frames,
+				    GFP_KERNEL);
+		if (!pdx->PixelUrb)
+			pdx->PixelUrb =
+			    kmalloc(sizeof(struct urb **) * pdx->num_frames,
+				    GFP_KERNEL);
+		if (!pdx->maplist_numPagesMapped)
+			pdx->maplist_numPagesMapped =
+			    vmalloc(sizeof(unsigned int) * pdx->num_frames);
+		if (!pdx->pendedPixelUrbs)
+			pdx->pendedPixelUrbs =
+			    kmalloc(sizeof(char *) * pdx->num_frames,
+				    GFP_KERNEL);
+		return 0;
+	default:
+		dbg("%s\n", "No IOCTL found");
+		break;
+
+	}
+	/* return that we did not understand this ioctl call */
+	dbg("Returning -ENOTTY");
+	return -ENOTTY;
+}
+
+static void piusb_write_bulk_callback(struct urb *urb)
+{
+	struct device_extension *pdx = urb->context;
+	int status = urb->status;
+
+	/* sync/async unlink faults aren't errors */
+	if (status && !(status == -ENOENT || status == -ECONNRESET))
+		dev_dbg(&urb->dev->dev,
+			"%s - nonzero write bulk status received: %d",
+			__func__, status);
+
+	pdx->pendingWrite = 0;
+	usb_buffer_free(urb->dev, urb->transfer_buffer_length,
+			urb->transfer_buffer, urb->transfer_dma);
+}
+
+int piusb_output(struct ioctl_struct * io, unsigned char *uBuf, int len,
+		 struct device_extension *pdx)
+{
+	struct urb *urb = NULL;
+	int err = 0;
+	unsigned char *kbuf = NULL;
+
+	urb = usb_alloc_urb(0, GFP_KERNEL);
+	if (urb != NULL) {
+		kbuf =
+		    usb_buffer_alloc(pdx->udev, len, GFP_KERNEL,
+				     &urb->transfer_dma);
+		if (!kbuf) {
+			info("buffer_alloc failed\n");
+			return -ENOMEM;
+		}
+		memcpy(kbuf, uBuf, len);
+		usb_fill_bulk_urb(urb, pdx->udev, pdx->hEP[io->endpoint], kbuf,
+				  len, piusb_write_bulk_callback, pdx);
+		urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
+		err = usb_submit_urb(urb, GFP_KERNEL);
+		if (err) {
+			dev_err(&pdx->udev->dev,
+				"WRITE ERROR:submit urb error = %d\n", err);
+		}
+		pdx->pendingWrite = 1;
+		usb_free_urb(urb);
+	}
+	return -EINPROGRESS;
+}
+
+static int UnMapUserBuffer(struct device_extension *pdx)
+{
+	int i = 0;
+	int k = 0;
+	unsigned int epAddr;
+	for (k = 0; k < pdx->num_frames; k++) {
+		dbg("Killing Urbs for Frame %d", k);
+		for (i = 0; i < pdx->sgEntries[k]; i++) {
+			usb_kill_urb(pdx->PixelUrb[k][i]);
+			usb_free_urb(pdx->PixelUrb[k][i]);
+			pdx->pendedPixelUrbs[k][i] = 0;
+		}
+		dbg("Urb error count = %d", errCnt);
+		errCnt = 0;
+		dbg("Urbs free'd and Killed for Frame %d", k);
+	}
+
+	for (k = 0; k < pdx->num_frames; k++) {
+		if (pdx->iama == PIXIS_PID)	//if so, which EP should we map this frame to
+		{
+			if (k % 2)	//check to see if this should use EP4(PONG)
+			{
+				epAddr = pdx->hEP[3];	//PONG, odd frames
+			} else {
+				epAddr = pdx->hEP[2];	//PING, even frames and zero
+			}
+		} else		//ST133 only has 1 endpoint for Pixel data transfer
+		{
+			epAddr = pdx->hEP[0];
+		}
+		usb_buffer_unmap_sg(pdx->udev, epAddr, pdx->sgl[k],
+				    pdx->maplist_numPagesMapped[k]);
+		for (i = 0; i < pdx->maplist_numPagesMapped[k]; i++) {
+			page_cache_release(pdx->sgl[k][i].page_link);
+		}
+		kfree(pdx->sgl[k]);
+		kfree(pdx->PixelUrb[k]);
+		kfree(pdx->pendedPixelUrbs[k]);
+		pdx->sgl[k] = NULL;
+		pdx->PixelUrb[k] = NULL;
+		pdx->pendedPixelUrbs[k] = NULL;
+	}
+	kfree(pdx->sgEntries);
+	vfree(pdx->maplist_numPagesMapped);
+	pdx->sgEntries = NULL;
+	pdx->maplist_numPagesMapped = NULL;
+	kfree(pdx->sgl);
+	kfree(pdx->pendedPixelUrbs);
+	kfree(pdx->PixelUrb);
+	pdx->sgl = NULL;
+	pdx->pendedPixelUrbs = NULL;
+	pdx->PixelUrb = NULL;
+	return 0;
+}
+
+static void piusb_readPIXEL_callback(struct urb *urb)
+{
+	int i = 0;
+	struct device_extension *pdx = urb->context;
+	int status = urb->status;
+
+	if (status && !(status == -ENOENT || status == -ECONNRESET)) {
+		dbg("%s - nonzero read bulk status received: %d", __func__,
+		    status);
+		dbg("Error in read EP2 callback");
+		dbg("FrameIndex = %d", pdx->frameIdx);
+		dbg("Bytes received before problem occurred = %d",
+		    pdx->bulk_in_byte_trk);
+		dbg("Urb Idx = %d", pdx->urbIdx);
+		pdx->pendedPixelUrbs[pdx->frameIdx][pdx->urbIdx] = 0;
+	} else {
+		pdx->bulk_in_byte_trk += urb->actual_length;
+		{
+			i = usb_submit_urb(urb, GFP_ATOMIC);	//resubmit the URB
+			if (i) {
+				errCnt++;
+				if (i != lastErr) {
+					dbg("submit urb in callback failed with error code %d", i);
+					lastErr = i;
+				}
+			} else {
+				pdx->urbIdx++;	//point to next URB when we callback
+				if (pdx->bulk_in_byte_trk >= pdx->frameSize) {
+					pdx->bulk_in_size_returned =
+					    pdx->bulk_in_byte_trk;
+					pdx->bulk_in_byte_trk = 0;
+					pdx->gotPixelData = 1;
+					pdx->frameIdx =
+					    ((pdx->frameIdx +
+					      1) % pdx->num_frames);
+					pdx->urbIdx = 0;
+				}
+			}
+		}
+	}
+}
+
+/* MapUserBuffer(
+	inputs:
+	struct ioctl_struct *io - structure containing user address, frame #, and size
+	struct device_extension *pdx - the PIUSB device extension
+	returns:
+	int - status of the task
+	Notes:
+	MapUserBuffer maps a buffer passed down through an ioctl.  The user buffer is Page Aligned by the app
+	and then passed down.  The function get_free_pages(...) does the actual mapping of the buffer from user space to
+	kernel space.  From there a scatterlist is created from all the pages.  The next function called is to usb_buffer_map_sg
+	which allocated DMA addresses for each page, even coalescing them if possible.  The DMA address is placed in the scatterlist
+	structure.  The function returns the number of DMA addresses.  This may or may not be equal to the number of pages that
+	the user buffer uses.  We then build an URB for each DMA address and then submit them.
+*/
+//int MapUserBuffer( unsigned long uaddr, unsigned long numbytes, unsigned long frameInfo, struct device_extension *pdx )
+static int MapUserBuffer(struct ioctl_struct *io, struct device_extension *pdx)
+{
+	unsigned long uaddr;
+	unsigned long numbytes;
+	int frameInfo;		//which frame we're mapping
+	unsigned int epAddr = 0;
+	unsigned long count = 0;
+	int i = 0;
+	int k = 0;
+	int err = 0;
+	struct page **maplist_p;
+	int numPagesRequired;
+	frameInfo = io->numFrames;
+	uaddr = (unsigned long)io->pData;
+	numbytes = io->numbytes;
+
+	if (pdx->iama == PIXIS_PID)	//if so, which EP should we map this frame to
+	{
+		if (frameInfo % 2)	//check to see if this should use EP4(PONG)
+		{
+			epAddr = pdx->hEP[3];	//PONG, odd frames
+		} else {
+			epAddr = pdx->hEP[2];	//PING, even frames and zero
+		}
+		dbg("Pixis Frame #%d: EP=%d", frameInfo,
+		    (epAddr == pdx->hEP[2]) ? 2 : 4);
+	} else			//ST133 only has 1 endpoint for Pixel data transfer
+	{
+		epAddr = pdx->hEP[0];
+		dbg("ST133 Frame #%d: EP=2", frameInfo);
+	}
+	count = numbytes;
+	dbg("UserAddress = 0x%08lX", uaddr);
+	dbg("numbytes = %d", (int)numbytes);
+	//number of pages to map the entire user space DMA buffer
+	numPagesRequired =
+	    ((uaddr & ~PAGE_MASK) + count + ~PAGE_MASK) >> PAGE_SHIFT;
+	dbg("Number of pages needed = %d", numPagesRequired);
+	maplist_p = vmalloc(numPagesRequired * sizeof(struct page));	//, GFP_ATOMIC);
+	if (!maplist_p) {
+		dbg("Can't Allocate Memory for maplist_p");
+		return -ENOMEM;
+	}
+	//map the user buffer to kernel memory
+	down_write(&current->mm->mmap_sem);
+	pdx->maplist_numPagesMapped[frameInfo] = get_user_pages(current, current->mm, (uaddr & PAGE_MASK), numPagesRequired, WRITE, 0,	//Don't Force
+								maplist_p,
+								NULL);
+	up_write(&current->mm->mmap_sem);
+	dbg("Number of pages mapped = %d",
+	    pdx->maplist_numPagesMapped[frameInfo]);
+	for (i = 0; i < pdx->maplist_numPagesMapped[frameInfo]; i++)
+		flush_dcache_page(maplist_p[i]);
+	if (!pdx->maplist_numPagesMapped[frameInfo]) {
+		dbg("get_user_pages() failed");
+		vfree(maplist_p);
+		return -ENOMEM;
+	}
+	//need to create a scatterlist that spans each frame that can fit into the mapped buffer
+	pdx->sgl[frameInfo] =
+	    kmalloc((pdx->maplist_numPagesMapped[frameInfo] *
+		     sizeof(struct scatterlist)), GFP_ATOMIC);
+	if (!pdx->sgl[frameInfo]) {
+		vfree(maplist_p);
+		dbg("can't allocate mem for sgl");
+		return -ENOMEM;
+	}
+	pdx->sgl[frameInfo][0].page_link = maplist_p[0];
+	pdx->sgl[frameInfo][0].offset = uaddr & ~PAGE_MASK;
+	if (pdx->maplist_numPagesMapped[frameInfo] > 1) {
+		pdx->sgl[frameInfo][0].length =
+		    PAGE_SIZE - pdx->sgl[frameInfo][0].offset;
+		count -= pdx->sgl[frameInfo][0].length;
+		for (k = 1; k < pdx->maplist_numPagesMapped[frameInfo]; k++) {
+			pdx->sgl[frameInfo][k].offset = 0;
+			pdx->sgl[frameInfo][k].page_link = maplist_p[k];
+			pdx->sgl[frameInfo][k].length =
+			    (count < PAGE_SIZE) ? count : PAGE_SIZE;
+			count -= PAGE_SIZE;	//example had PAGE_SIZE here;
+		}
+	} else {
+		pdx->sgl[frameInfo][0].length = count;
+	}
+	pdx->sgEntries[frameInfo] =
+	    usb_buffer_map_sg(pdx->udev, epAddr, pdx->sgl[frameInfo],
+			      pdx->maplist_numPagesMapped[frameInfo]);
+	dbg("number of sgEntries = %d", pdx->sgEntries[frameInfo]);
+	pdx->userBufMapped = 1;
+	vfree(maplist_p);
+	//Create and Send the URB's for each s/g entry
+	pdx->PixelUrb[frameInfo] =
+	    kmalloc(pdx->sgEntries[frameInfo] * sizeof(struct urb *),
+		    GFP_KERNEL);
+	if (!pdx->PixelUrb[frameInfo]) {
+		dbg("Can't Allocate Memory for Urb");
+		return -ENOMEM;
+	}
+	for (i = 0; i < pdx->sgEntries[frameInfo]; i++) {
+		pdx->PixelUrb[frameInfo][i] = usb_alloc_urb(0, GFP_KERNEL);	//0 because we're using BULK transfers
+		usb_fill_bulk_urb(pdx->PixelUrb[frameInfo][i],
+				  pdx->udev,
+				  epAddr,
+				  (dma_addr_t *) sg_dma_address(&pdx->
+								sgl[frameInfo]
+								[i]),
+				  sg_dma_len(&pdx->sgl[frameInfo][i]),
+				  piusb_readPIXEL_callback, (void *)pdx);
+		pdx->PixelUrb[frameInfo][i]->transfer_dma =
+		    sg_dma_address(&pdx->sgl[frameInfo][i]);
+		pdx->PixelUrb[frameInfo][i]->transfer_flags =
+		    URB_NO_TRANSFER_DMA_MAP | URB_NO_INTERRUPT;
+	}
+	pdx->PixelUrb[frameInfo][--i]->transfer_flags &= ~URB_NO_INTERRUPT;	//only interrupt when last URB completes
+	pdx->pendedPixelUrbs[frameInfo] =
+	    kmalloc((pdx->sgEntries[frameInfo] * sizeof(char)), GFP_KERNEL);
+	if (!pdx->pendedPixelUrbs[frameInfo])
+		dbg("Can't allocate Memory for pendedPixelUrbs");
+	for (i = 0; i < pdx->sgEntries[frameInfo]; i++) {
+		err = usb_submit_urb(pdx->PixelUrb[frameInfo][i], GFP_ATOMIC);
+		if (err) {
+			dbg("%s %d\n", "submit urb error =", err);
+			pdx->pendedPixelUrbs[frameInfo][i] = 0;
+			return err;
+		} else
+			pdx->pendedPixelUrbs[frameInfo][i] = 1;;
+	}
+	return 0;
+}
+
+static struct file_operations piusb_fops = {
+	.owner = THIS_MODULE,
+	.ioctl = piusb_ioctl,
+	.open = piusb_open,
+	.release = piusb_release,
+};
+
+static struct usb_class_driver piusb_class = {
+	.name = "usb/rspiusb%d",
+	.fops = &piusb_fops,
+	.minor_base = PIUSB_MINOR_BASE,
+};
+
+/**
+ *	piusb_probe
+ *
+ *	Called by the usb core when a new device is connected that it thinks
+ *	this driver might be interested in.
+ */
+static int piusb_probe(struct usb_interface *interface,
+		       const struct usb_device_id *id)
+{
+	struct device_extension *pdx = NULL;
+	struct usb_host_interface *iface_desc;
+	struct usb_endpoint_descriptor *endpoint;
+	int i;
+	int retval = -ENOMEM;
+
+	dev_dbg(&interface->dev, "%s - Looking for PI USB Hardware", __func__);
+
+	pdx = kzalloc(sizeof(struct device_extension), GFP_KERNEL);
+	if (pdx == NULL) {
+		dev_err(&interface->dev, "Out of memory\n");
+		goto error;
+	}
+	kref_init(&pdx->kref);
+	pdx->udev = usb_get_dev(interface_to_usbdev(interface));
+	pdx->interface = interface;
+	iface_desc = interface->cur_altsetting;
+
+	/* See if the device offered us matches what we can accept */
+	if ((pdx->udev->descriptor.idVendor != VENDOR_ID)
+	    || ((pdx->udev->descriptor.idProduct != PIXIS_PID)
+		&& (pdx->udev->descriptor.idProduct != ST133_PID))) {
+		return -ENODEV;
+	}
+	pdx->iama = pdx->udev->descriptor.idProduct;
+
+	if (debug) {
+		if (pdx->udev->descriptor.idProduct == PIXIS_PID)
+			dbg("PIUSB:Pixis Camera Found");
+		else
+			dbg("PIUSB:ST133 USB Controller Found");
+		if (pdx->udev->speed == USB_SPEED_HIGH)
+			dbg("Highspeed(USB2.0) Device Attached");
+		else
+			dbg("Lowspeed (USB1.1) Device Attached");
+
+		dbg("NumEndpoints in Configuration: %d",
+		    iface_desc->desc.bNumEndpoints);
+	}
+	for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
+		endpoint = &iface_desc->endpoint[i].desc;
+		if (debug) {
+			dbg("Endpoint[%d]->bDescriptorType = %d", i,
+			    endpoint->bDescriptorType);
+			dbg("Endpoint[%d]->bEndpointAddress = 0x%02X", i,
+			    endpoint->bEndpointAddress);
+			dbg("Endpoint[%d]->bbmAttributes = %d", i,
+			    endpoint->bmAttributes);
+			dbg("Endpoint[%d]->MaxPacketSize = %d\n", i,
+			    endpoint->wMaxPacketSize);
+		}
+		if ((endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) ==
+		    USB_ENDPOINT_XFER_BULK) {
+			if (endpoint->bEndpointAddress & USB_DIR_IN)
+				pdx->hEP[i] =
+				    usb_rcvbulkpipe(pdx->udev,
+						    endpoint->bEndpointAddress);
+			else
+				pdx->hEP[i] =
+				    usb_sndbulkpipe(pdx->udev,
+						    endpoint->bEndpointAddress);
+		}
+	}
+	usb_set_intfdata(interface, pdx);
+	retval = usb_register_dev(interface, &piusb_class);
+	if (retval) {
+		err("Not able to get a minor for this device.");
+		usb_set_intfdata(interface, NULL);
+		goto error;
+	}
+	pdx->present = 1;
+
+	/* we can register the device now, as it is ready */
+	pdx->minor = interface->minor;
+	/* let the user know what node this device is now attached to */
+	dbg("PI USB2.0 device now attached to piusb-%d", pdx->minor);
+	return 0;
+
+      error:
+	if (pdx)
+		kref_put(&pdx->kref, piusb_delete);
+	return retval;
+}
+
+/**
+ *	piusb_disconnect
+ *
+ *	Called by the usb core when the device is removed from the system.
+ *
+ *	This routine guarantees that the driver will not submit any more urbs
+ *	by clearing pdx->udev.  It is also supposed to terminate any currently
+ *	active urbs.  Unfortunately, usb_bulk_msg(), used in piusb_read(), does
+ *	not provide any way to do this.  But at least we can cancel an active
+ *	write.
+ */
+static void piusb_disconnect(struct usb_interface *interface)
+{
+	struct device_extension *pdx;
+	int minor = interface->minor;
+	lock_kernel();
+	pdx = usb_get_intfdata(interface);
+	usb_set_intfdata(interface, NULL);
+	/* give back our minor */
+	usb_deregister_dev(interface, &piusb_class);
+	unlock_kernel();
+	/* prevent device read, write and ioctl */
+	pdx->present = 0;
+	kref_put(&pdx->kref, piusb_delete);
+	dbg("PI USB2.0 device #%d now disconnected\n", minor);
+}
+
+static struct usb_driver piusb_driver = {
+	.name = "sub",
+	.probe = piusb_probe,
+	.disconnect = piusb_disconnect,
+	.id_table = pi_device_table,
+};
+
+/**
+ *	piusb_init
+ */
+static int __init piusb_init(void)
+{
+	int result;
+	/* register this driver with the USB subsystem */
+	result = usb_register(&piusb_driver);
+	if (result) {
+		printk(KERN_ERR KBUILD_MODNAME
+		       ": usb_register failed. Error number %d\n", result);
+		return result;
+	}
+	printk(KERN_INFO KBUILD_MODNAME ":%s: %s\n", DRIVER_DESC,
+	       DRIVER_VERSION);
+	return 0;
+}
+
+/**
+ *	piusb_exit
+ */
+static void __exit piusb_exit(void)
+{
+	/* deregister this driver with the USB subsystem */
+	usb_deregister(&piusb_driver);
+}
+
+module_init(piusb_init);
+module_exit(piusb_exit);
+
+/* Module parameters */
+module_param(debug, int, 0);
+MODULE_PARM_DESC(debug, "Debug enabled or not");
+
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL v2");
--- /dev/null
+++ b/drivers/staging/rspiusb.h
@@ -0,0 +1,25 @@
+#ifndef __RSPIUSB_H
+#define __RSPIUSB_H
+
+#define PIUSB_MAGIC		'm'
+#define PIUSB_IOCTL_BASE	192
+#define PIUSB_GETVNDCMD		_IOR(PIUSB_MAGIC, PIUSB_IOCTL_BASE + 1, struct ioctl_struct)
+#define PIUSB_SETVNDCMD		_IOW(PIUSB_MAGIC, PIUSB_IOCTL_BASE + 2, struct ioctl_struct)
+#define PIUSB_WRITEPIPE		_IOW(PIUSB_MAGIC, PIUSB_IOCTL_BASE + 3, struct ioctl_struct)
+#define PIUSB_READPIPE		_IOR(PIUSB_MAGIC, PIUSB_IOCTL_BASE + 4, struct ioctl_struct)
+#define PIUSB_SETFRAMESIZE	_IOW(PIUSB_MAGIC, PIUSB_IOCTL_BASE + 5, struct ioctl_struct)
+#define PIUSB_WHATCAMERA	_IO(PIUSB_MAGIC,  PIUSB_IOCTL_BASE + 6)
+#define PIUSB_USERBUFFER	_IOW(PIUSB_MAGIC, PIUSB_IOCTL_BASE + 7, struct ioctl_struct)
+#define PIUSB_ISHIGHSPEED	_IO(PIUSB_MAGIC,  PIUSB_IOCTL_BASE + 8)
+#define PIUSB_UNMAP_USERBUFFER	_IOW(PIUSB_MAGIC, PIUSB_IOCTL_BASE + 9, struct ioctl_struct)
+
+struct ioctl_struct {
+	unsigned char cmd;
+	unsigned long numbytes;
+	unsigned char dir;	//1=out;0=in
+	int endpoint;
+	int numFrames;
+	unsigned char *pData;
+};
+
+#endif
--- /dev/null
+++ b/drivers/staging/rspiusb.README
@@ -0,0 +1,22 @@
+This driver is for the Princeton Instruments USB camera.
+
+It needs lots of work to get it into the main drivers/usb/ subdirectory:
+
+Any patches to do any of the following changes are greatly appreciated:
+
+	- make checkpatch.pl clean
+	- coding style fixups (typedefs, etc.)
+	- get it to build properly
+	- audit ioctls
+	- remove ioctls if possible
+	- assign proper minor number
+	- remove dbg() macro
+	- lots of general cleanups
+	- review locking
+
+Please send patches to:
+	Greg Kroah-Hartman <gregkh@suse.de>
+and CC:
+	Judd Montgomery <judd@jpilot.org>
+	Jeff Frontz <jeff.frontz@gmail.com>
+as they have this device and can test any needed changes.

-- 

[patch 03/04] Staging: add Kconfig entries and Makefile infrastructure

[Greg KH]

[-- Attachment #1: staging-add-kconfig-entries-and-makefile-infrastructure.patch --]
[-- Type: text/plain, Size: 1867 bytes --]

This hooks up the drivers/staging directory to the build system

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/Kconfig          |    2 ++
 drivers/Makefile         |    1 +
 drivers/staging/Kconfig  |   27 +++++++++++++++++++++++++++
 drivers/staging/Makefile |    2 ++
 4 files changed, 32 insertions(+)

--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -101,4 +101,6 @@ source "drivers/auxdisplay/Kconfig"
 source "drivers/uio/Kconfig"
 
 source "drivers/xen/Kconfig"
+
+source "drivers/staging/Kconfig"
 endmenu
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -99,3 +99,4 @@ obj-$(CONFIG_OF)		+= of/
 obj-$(CONFIG_SSB)		+= ssb/
 obj-$(CONFIG_VIRTIO)		+= virtio/
 obj-$(CONFIG_REGULATOR)		+= regulator/
+obj-$(CONFIG_STAGING)		+= staging/
--- /dev/null
+++ b/drivers/staging/Kconfig
@@ -0,0 +1,27 @@
+menuconfig STAGING
+	bool "Staging drivers"
+	default n
+	---help---
+	  This option allows you to select a number of drivers that are
+	  not of the "normal" Linux kernel quality level.  These drivers
+	  are placed here in order to get a wider audience for use of
+	  them.  Please note that these drivers are under heavy
+	  development, may or may not work, and may contain userspace
+	  interfaces that most likely will be changed in the near
+	  future.
+
+	  Using any of these drivers will taint your kernel which might
+	  affect support options from both the community, and various
+	  commercial support orginizations.
+
+	  If you wish to work on these drivers, to help improve them, or
+	  to report problems you have with them, please see the
+	  driver_name.README file in the drivers/staging/ directory to
+	  see what needs to be worked on, and who to contact.
+
+	  If in doubt, say N here.
+
+if STAGING
+
+
+endif # STAGING
--- /dev/null
+++ b/drivers/staging/Makefile
@@ -0,0 +1,2 @@
+# Makefile for staging directory
+

-- 

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Parag Warudkar]

On Wed, Sep 24, 2008 at 7:00 PM, Greg KH <gregkh@suse.de> wrote:
> So, does this all look good to everyone?  Any questions/issues?
>

I sure hope this does not end up like EXPERIMENTAL although it
essentially does duplicate the intent of EXPERIMENTAL.
(In other words - drivers live there for ever in staging mode, we
print warnings and generally nobody cares about the problem since the
kernel is tainted.)

That aside please at least substitute the word CRAP with something
better - like TAINT_NON_PRODUCTION or TAINT_UNRELIABLE or
TAINT_WORK_IN_PROGRESS or TAINT_EXPERIMENTAL . Arguably
TAINT_EXPERIMENTAL could also be used for known broken
CONFIG_EXPERIMENTAL items. It might also be better to change the
staging directory name to non-production or experimental - but that's
just my preference.

Also, I suppose it would be useful for Production machines to have a
kernel command line flag or something to say don't load staging
modules - for instance to prevent against automatic loading on drivers
from staging directory to support some oddball device etc.

Thinking more about it - could this whole thing not be achieved by
setting per module experimental flag and refusing to insmod'ing
experimental modules if -f was not specified. I believe force loading
also taints the kernel? All drivers intended for staging can set that
flag  - this way we don't need another TAINT flag and there is no need
for the directory name hack.

Parag

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Randy Dunlap]

On Wed, 24 Sep 2008 19:39:42 -0400 Parag Warudkar wrote:

> On Wed, Sep 24, 2008 at 7:00 PM, Greg KH <gregkh@suse.de> wrote:
> > So, does this all look good to everyone?  Any questions/issues?
> >
> 
> I sure hope this does not end up like EXPERIMENTAL although it
> essentially does duplicate the intent of EXPERIMENTAL.
> (In other words - drivers live there for ever in staging mode, we
> print warnings and generally nobody cares about the problem since the
> kernel is tainted.)
> 
> That aside please at least substitute the word CRAP with something
> better - like TAINT_NON_PRODUCTION or TAINT_UNRELIABLE or
> TAINT_WORK_IN_PROGRESS or TAINT_EXPERIMENTAL . Arguably
> TAINT_EXPERIMENTAL could also be used for known broken
> CONFIG_EXPERIMENTAL items. It might also be better to change the
> staging directory name to non-production or experimental - but that's
> just my preference.
> 
> Also, I suppose it would be useful for Production machines to have a
> kernel command line flag or something to say don't load staging
> modules - for instance to prevent against automatic loading on drivers
> from staging directory to support some oddball device etc.
> 
> Thinking more about it - could this whole thing not be achieved by
> setting per module experimental flag and refusing to insmod'ing
> experimental modules if -f was not specified. I believe force loading
> also taints the kernel? All drivers intended for staging can set that
> flag  - this way we don't need another TAINT flag and there is no need
> for the directory name hack.

Thanks.  I agree with Parag's comments.

Looks like overkill/duplication.

---
~Randy

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Greg KH]

On Wed, Sep 24, 2008 at 06:03:16PM -0700, Randy Dunlap wrote:
> Thanks.  I agree with Parag's comments.
> 
> Looks like overkill/duplication.

I disagree, see my response to Parag's comments :)

thanks,

greg k-h

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Greg KH]

On Wed, Sep 24, 2008 at 07:39:42PM -0400, Parag Warudkar wrote:
> On Wed, Sep 24, 2008 at 7:00 PM, Greg KH <gregkh@suse.de> wrote:
> > So, does this all look good to everyone?  Any questions/issues?
> >
> 
> I sure hope this does not end up like EXPERIMENTAL although it
> essentially does duplicate the intent of EXPERIMENTAL.
> (In other words - drivers live there for ever in staging mode, we
> print warnings and generally nobody cares about the problem since the
> kernel is tainted.)

No, this is much different from EXPERIMENTAL.  That flag is pretty much
useless right now.  This is for a temporary landing place for drivers
that are not good enough to be merged, yet are useful enough for some
people to use.

Examples of this is the USB driver I posted, some network drivers that
are in -staging that only work on x86 boxes, and drivers that have
userspace interfaces that are "wrong" and need to be changed (reading
files from /etc is one example.)

All of those types of drivers are not capable of being merged today, and
EXPERIMENTAL doesn't mean anything there.

Also, api changes do not have to propagate into the drivers/staging/
directory.  I'll work to keep up with them, keeping everything working
properly, just like I have been with the external -staging tree.  This
is just pushing it into the tree to give it much wider exposure and draw
from more developers makeing it easier to give them the proper credit
for this clean-up work.

> That aside please at least substitute the word CRAP with something
> better - like TAINT_NON_PRODUCTION or TAINT_UNRELIABLE or
> TAINT_WORK_IN_PROGRESS or TAINT_EXPERIMENTAL .

Why, that word is only internal, nothing outside of the kernel sees that
flag at all, no user will ever know this.

And if we leave it as TAINT_CRAP, and a developer sees it, perhaps it
will cause them to make their code cleaner next time around :)

> Also, I suppose it would be useful for Production machines to have a
> kernel command line flag or something to say don't load staging
> modules - for instance to prevent against automatic loading on drivers
> from staging directory to support some oddball device etc.

I can easily add a "no_crap" flag to the command line.  Oops, there's
that word going out to userspace, how about "no_staging"?

> Thinking more about it - could this whole thing not be achieved by
> setting per module experimental flag and refusing to insmod'ing
> experimental modules if -f was not specified. I believe force loading
> also taints the kernel? All drivers intended for staging can set that
> flag  - this way we don't need another TAINT flag and there is no need
> for the directory name hack.

This keeps these kinds of drivers in one place, obvious to all that work
needs to be done, and userspace interfaces can, and usually will change
for such drivers.

I think the boat has left on making EXPERIMENTAL mean anything anymore,
but if you or anyone else wants to clean up the tree, and free it up,
then I would reconsider using it here instead.  But you can't start
making it something that means more than it does today, as I can easily
see that breaking systems that currently rely on those drivers.

thanks,

greg k-h

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Parag Warudkar]

On Wed, Sep 24, 2008 at 10:06 PM, Greg KH <gregkh@suse.de> wrote:
> No, this is much different from EXPERIMENTAL.  That flag is pretty much
> useless right now.  This is for a temporary landing place for drivers
> that are not good enough to be merged, yet are useful enough for some
> people to use.

How? TAINT_EXPERIMENTAL (I'll stick to that, thanks :) and
CONFIG_EXPERIMENTAL are no different - neither to users nor to
developers. Here is why -
Both try to do the same thing - let people use the drivers on their
own risk (as if the stable ones are developer's risk - but let's keep
it aside for the moment) and give developers a chance to keep the code
in sync with mainline and improve it per user problem reports or
generally make it better.

You might try to differentiate between them on the basis of relative
brokenness or crappiness if you will - but it is essentially the same
- code that is not ideal for merge in mainline, code that needs user
testing to trash out problems, and code that need to be in sync with
mainline and code that users want to use in order to be able to use
their hardware. I fail to see how this is different at all.

>
> Examples of this is the USB driver I posted, some network drivers that
> are in -staging that only work on x86 boxes, and drivers that have
> userspace interfaces that are "wrong" and need to be changed (reading
> files from /etc is one example.)
>

I don't see a reason to further classify and label the experimental
code - it is experimental. That classification suffices.

> Also, api changes do not have to propagate into the drivers/staging/
> directory.  I'll work to keep up with them, keeping everything working
> properly, just like I have been with the external -staging tree.  This
> is just pushing it into the tree to give it much wider exposure and draw
> from more developers makeing it easier to give them the proper credit
> for this clean-up work.

Sure. Merge them under EXPERIMENTAL - may be with a big fat colored
KConfig warning about what is broken.
Tainting and labeling it staging does nothing of any value add. Sure
you can have a staging directory in the tree and dump all the
unmergeable code there if that gives a sense of isolation but I do not
see a point in letting users build the staging code, loading it
without their intervention and then printing a warning and tainting
the kernel.

So what if there is a oops report tomorrow and we know it is Tainted :
EXPERIMENTAL -  OOPS reports generally are very indicative of  where
the problem is coming from and the knowledge that certain broken
driver is loaded is just fine to be outside the kernel - no need for
the TAINT intimidation which drives away users from reporting it and
developers from addressing it.


> I think the boat has left on making EXPERIMENTAL mean anything anymore,
> but if you or anyone else wants to clean up the tree, and free it up,
> then I would reconsider using it here instead.  But you can't start
> making it something that means more than it does today, as I can easily
> see that breaking systems that currently rely on those drivers.

There's the clue - this _will_ happen with staging - I can almost see it.
So why not do it under one existing monster of an umbrella - or do you
have plans to make sure you are not going to add a new staging driver
unless the existing ones graduate to stable? Even if you do -  doable
under EXPERIMENTAL.

Parag

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Greg KH]

On Wed, Sep 24, 2008 at 10:59:03PM -0400, Parag Warudkar wrote:
> On Wed, Sep 24, 2008 at 10:06 PM, Greg KH <gregkh@suse.de> wrote:
> > No, this is much different from EXPERIMENTAL.  That flag is pretty much
> > useless right now.  This is for a temporary landing place for drivers
> > that are not good enough to be merged, yet are useful enough for some
> > people to use.
> 
> How? TAINT_EXPERIMENTAL (I'll stick to that, thanks :) and
> CONFIG_EXPERIMENTAL are no different - neither to users nor to
> developers. Here is why -

Sorry, no, the EXPERIMENTAL horse has left the barn.  If you want to run
after it and round it up and bring it back, that's great, but that is
going to be a lot of work that I'm sure not going to do.

> Both try to do the same thing - let people use the drivers on their
> own risk (as if the stable ones are developer's risk - but let's keep
> it aside for the moment) and give developers a chance to keep the code
> in sync with mainline and improve it per user problem reports or
> generally make it better.
> 
> You might try to differentiate between them on the basis of relative
> brokenness or crappiness if you will - but it is essentially the same
> - code that is not ideal for merge in mainline, code that needs user
> testing to trash out problems, and code that need to be in sync with
> mainline and code that users want to use in order to be able to use
> their hardware. I fail to see how this is different at all.

It is not different, except by name only.  Don't bike-shed :)

> > Examples of this is the USB driver I posted, some network drivers that
> > are in -staging that only work on x86 boxes, and drivers that have
> > userspace interfaces that are "wrong" and need to be changed (reading
> > files from /etc is one example.)
> >
> 
> I don't see a reason to further classify and label the experimental
> code - it is experimental. That classification suffices.

Again, no, the current EXPERMENTAL marking is pointless and a mess.  If
that were to be cleaned up then I'll reconsider.

> > Also, api changes do not have to propagate into the drivers/staging/
> > directory.  I'll work to keep up with them, keeping everything working
> > properly, just like I have been with the external -staging tree.  This
> > is just pushing it into the tree to give it much wider exposure and draw
> > from more developers makeing it easier to give them the proper credit
> > for this clean-up work.
> 
> Sure. Merge them under EXPERIMENTAL - may be with a big fat colored
> KConfig warning about what is broken.
> Tainting and labeling it staging does nothing of any value add. Sure
> you can have a staging directory in the tree and dump all the
> unmergeable code there if that gives a sense of isolation but I do not
> see a point in letting users build the staging code, loading it
> without their intervention and then printing a warning and tainting
> the kernel.

It provides a fast way into the kernel for companies who do not stick
around to take the time to merge things in.  That's what the -staging
tree has been doing quite well for the past 6 months or so, with lots of
drivers moving into mainline, and 15 drivers currently residing in it.

This is moving that tree into the kernel to provide all of the reasons I
previously mentioned.

> So what if there is a oops report tomorrow and we know it is Tainted :
> EXPERIMENTAL -  OOPS reports generally are very indicative of  where
> the problem is coming from and the knowledge that certain broken
> driver is loaded is just fine to be outside the kernel - no need for
> the TAINT intimidation which drives away users from reporting it and
> developers from addressing it.

But I sure want to show such a marking, don't you?  It isn't costing
anything, and if a developer doesn't want to debug the kernel if such a
driver is loaded, this allows them to do this.  It was a requirement
that came out of the discussion at the kernel summit.

> > I think the boat has left on making EXPERIMENTAL mean anything anymore,
> > but if you or anyone else wants to clean up the tree, and free it up,
> > then I would reconsider using it here instead.  But you can't start
> > making it something that means more than it does today, as I can easily
> > see that breaking systems that currently rely on those drivers.
> 
> There's the clue - this _will_ happen with staging - I can almost see it.
> So why not do it under one existing monster of an umbrella - or do you
> have plans to make sure you are not going to add a new staging driver
> unless the existing ones graduate to stable? Even if you do -  doable
> under EXPERIMENTAL.

No, it will not happen, the code is self-contained in a sub-directory,
with an active maintainer, and lots of active helper developers (as have
been sending me patches over the past weeks.)  If this does happen, and
drivers/staging/ grows to be a large dumping ground with no movement out
of it, then I'll worry about that then.  But I really don't think it
will happen.

thanks,

greg k-h

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Parag Warudkar]

On Thu, Sep 25, 2008 at 12:21 AM, Greg KH <gregkh@suse.de> wrote:

>
> It is not different, except by name only.  Don't bike-shed :)

The whole concept is a bike shed - disproportionate importance to
labeling same things with different name.
So it should come as no surprise that we are discussing the need for
trivial duplications.


> It provides a fast way into the kernel for companies who do not stick
> around to take the time to merge things in.  That's what the -staging
> tree has been doing quite well for the past 6 months or so, with lots of
> drivers moving into mainline, and 15 drivers currently residing in it.

Again - sure move the staging directory to the mainline tree, group
all those drivers under CONFIG_HALFBAKED and default the whole
category to N.
Name those driver modules with a _stg prefix and be done with it. No
need for the insanely useless module loading crap because -
1) You will happily load from that directory automatically if device
is present - user wants it or not
2) You want users to test it and report bugs and still warn them and
taint their kernel so any problems can be ignored.
3) OOPS reports are generally specific enough to identify the
peripheral driver was a culprit or not - TAINTING does not achieve
anything significant apart from intimidation and completely redundant
classification.

>
> But I sure want to show such a marking, don't you?  It isn't costing
> anything, and if a developer doesn't want to debug the kernel if such a
> driver is loaded, this allows them to do this.  It was a requirement
> that came out of the discussion at the kernel summit.

I am not sure why _anyone_ would want to since it serves nothing.

I will ask it again -

If you do not want to use EXPERIMENTAL - fine. How about you remove
the TAINT crap and do this instead -

1) Give a staging directory for all such low quality crap
2) Give a KConfig group "Staging Drivers (Low Quality/High Risk)" and
if that is selected allow users to individually select the crappy
drivers they want to actually use - default all entries to N
3) Name all modules under staging  with a _stg suffix or something unique
4) By default do NOT load anything with a _stg suffix - deal with this
in insmod code, not the kernel
5) Require that -f be specified to load _stg modules - which will
auto-taint the kernel

That will allow you to do what you want without touching kernel code -
OOPS report, just look for _stg and decided whether or not to pursue
the report.

>> There's the clue - this _will_ happen with staging - I can almost see it.
>> So why not do it under one existing monster of an umbrella - or do you
>> have plans to make sure you are not going to add a new staging driver
>> unless the existing ones graduate to stable? Even if you do -  doable
>> under EXPERIMENTAL.
>
> No, it will not happen, the code is self-contained in a sub-directory,
> with an active maintainer, and lots of active helper developers (as have
> been sending me patches over the past weeks.)  If this does happen, and
> drivers/staging/ grows to be a large dumping ground with no movement out
> of it, then I'll worry about that then.  But I really don't think it
> will happen.

That is good to hear - we will see :)

Thanks!
Parag

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Greg KH]

On Thu, Sep 25, 2008 at 07:02:28AM -0400, Parag Warudkar wrote:
> On Thu, Sep 25, 2008 at 12:21 AM, Greg KH <gregkh@suse.de> wrote:
> 
> >
> > It is not different, except by name only.  Don't bike-shed :)
> 
> The whole concept is a bike shed - disproportionate importance to
> labeling same things with different name.
> So it should come as no surprise that we are discussing the need for
> trivial duplications.

Heh, ok, so the basic premise of getting code that is not currently in
mergable shape into the tree earlier to get wider usage and testing is
something that you agree with?

If so, we can arm-wrestle over what to call it, one name is as good as
another, as long as we don't overload a currently used name like
EXPERIMENTAL, which Paul has so well explained is a mess right now.  And
I don't have the inclination to clean up that mess right now, I'm more
worried about bigger messes like these 15 horrible drivers I'm currently
sitting on in -staging.

If not, please let me know your objections.

thanks,

greg "green! The bikeshed must be green!" k-h

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Parag Warudkar]

On Thu, Sep 25, 2008 at 4:53 PM, Greg KH <gregkh@suse.de> wrote:
>
> Heh, ok, so the basic premise of getting code that is not currently in
> mergable shape into the tree earlier to get wider usage and testing is
> something that you agree with?

I don't think I got my point across - let me try again.

My disagreement was with getting crap code in mainline, re-classifying
it as something other than experimental when it is not, expecting
users to use it, printing warning when it is used, tainting the kernel
for even more harassment and then having developers not support it  as
a bonus - all cumulative. The naming part was also something that I
did not like but that like I said was just my preference and does not
matter because I disagree there is no need to TAINT  in first place.

I can imagine that getting crap code in mainline is helpful for some
class of users and developers - no problem we can have it in on that
basis - I give up my objection there.

But my objections to the other parts remain -  i.e. we should
definitely avoid the useless re-classification and TAINT, we should
change little or no other kernel code in the process of integrating
this crap, give enough deterrent for people to really think before
loading the crap code, and do not make it an official statement that
you will get no support on LKML if you load this driver. Because
certainly not all developers agree and we by definition of this
staging effort have an interest in fixing the code.

The below approach I referred few times earlier will allow us to do
exactly that - it would be good if you can tell me if this is
workable.

1) Give a staging directory for all such low quality crap
2) Give a KConfig group "Staging Drivers (Low Quality/High Risk)" and
if that is selected allow users to individually select the crappy
drivers they want to actually use - default all entries to N
3) Name all modules under staging  with a _stg suffix or something unique
4) By default do NOT load anything with a _stg suffix - deal with this
in insmod code, not the kernel
5) Require that -f be specified to load _stg modules - which will
auto-taint the kernel and developers can decide on their judgment /
situation whether or not to pursue it
 6) OOPS reports with force loaded taint and _stg in module list will
allow developers to decide whether or not to go after it

The above approach avoids re-classification/TAINTING, touches no
kernel code and does not load the crap code automatically and still
allows you to do what you intended.

Hopefully this doesn't sound like another "let us arm wrestle on what
to name it" - because it is clearly more than that!

Parag

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Greg KH]

On Thu, Sep 25, 2008 at 05:40:28PM -0400, Parag Warudkar wrote:
> On Thu, Sep 25, 2008 at 4:53 PM, Greg KH <gregkh@suse.de> wrote:
> >
> > Heh, ok, so the basic premise of getting code that is not currently in
> > mergable shape into the tree earlier to get wider usage and testing is
> > something that you agree with?
> 
> I don't think I got my point across - let me try again.
> 
> My disagreement was with getting crap code in mainline, re-classifying
> it as something other than experimental when it is not, expecting
> users to use it, printing warning when it is used, tainting the kernel
> for even more harassment and then having developers not support it  as
> a bonus - all cumulative. The naming part was also something that I
> did not like but that like I said was just my preference and does not
> matter because I disagree there is no need to TAINT  in first place.

I'm sorry we disagree here.  Also note that this goes against what a
number of us decided at the kernel summit, we want this code into the
tree as easily as possible.

> I can imagine that getting crap code in mainline is helpful for some
> class of users and developers - no problem we can have it in on that
> basis - I give up my objection there.

Great.

> But my objections to the other parts remain -  i.e. we should
> definitely avoid the useless re-classification and TAINT, we should
> change little or no other kernel code in the process of integrating
> this crap, give enough deterrent for people to really think before
> loading the crap code, and do not make it an official statement that
> you will get no support on LKML if you load this driver. Because
> certainly not all developers agree and we by definition of this
> staging effort have an interest in fixing the code.
> 
> The below approach I referred few times earlier will allow us to do
> exactly that - it would be good if you can tell me if this is
> workable.

So you now agree with the idea, just the implementation of the area
around the drivers, nice that's easy to work out.

> 1) Give a staging directory for all such low quality crap

Done in the patches I sent out.

> 2) Give a KConfig group "Staging Drivers (Low Quality/High Risk)" and
> if that is selected allow users to individually select the crappy
> drivers they want to actually use - default all entries to N

Done in the patches I sent out.

> 3) Name all modules under staging  with a _stg suffix or something unique

A name doesn't really matter here, the modinfo tag is just as
sufficient like I already did.

> 4) By default do NOT load anything with a _stg suffix - deal with this
> in insmod code, not the kernel

Um, no, I'm not going to force all userspace users to upgrade their
version of module-init-tools, JUST to prevent them from automatically
loading these drivers.  That's not going to happen, sorry.

> 5) Require that -f be specified to load _stg modules - which will
> auto-taint the kernel and developers can decide on their judgment /
> situation whether or not to pursue it

So you have to load the modules by "hand"?  Ick, no, that too is not
acceptable as it means no one will ever do it.  Don't break the
wonderful infrastructure we already have around the kernel of
auto-loading the proper driver for the proper hardware just because you
want to make the user jump through an extra step please.

>  6) OOPS reports with force loaded taint and _stg in module list will
> allow developers to decide whether or not to go after it

My patch set already does this, and it does so in a way that uniquely
distinguishes from the -f option, which some of us don't want to debug
as well.

> The above approach avoids re-classification/TAINTING, touches no
> kernel code and does not load the crap code automatically and still
> allows you to do what you intended.

What's the objection for the 9 extra lines in module.c, 2 lines in
panic.c, and 9 lines on scripts/mod/modpost.c?  Is this some huge
overhead that is unmaintainable?

Heck, the insmod changes would be more than that I imagine (and it would
be in modprobe, not insmod, it has to do with alias matching and that
chunk of code is _nasty_, I sure don't want to touch that.)

> Hopefully this doesn't sound like another "let us arm wrestle on what
> to name it" - because it is clearly more than that!

No, I really think it isn't more than that.  For some reason you are
afraid of another taint flag, why?  There is no extra overhead, and no
user needs to upgrade any userspace component at all (which, if you have
any experience with, you will know it just will not happen fast, if at
all for the large majority of users/developers.)

I don't want to make the kernel require a new version of
module-init-tools, and my current proposal of infrastructure changes
requires a massive core change of:

 Documentation/sysctl/kernel.txt |    1 +
 include/linux/kernel.h          |    1 +
 kernel/module.c                 |    9 +++++++++
 kernel/panic.c                  |    6 ++++--
 scripts/mod/modpost.c           |    9 +++++++++
5 files changed, 24 insertions(+), 2 deletions(-)

How much smaller do you expect this to get?

thanks,

greg k-h

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Parag Warudkar]

On Thu, Sep 25, 2008 at 6:04 PM, Greg KH <gregkh@suse.de> wrote:
>
> What's the objection for the 9 extra lines in module.c, 2 lines in
> panic.c, and 9 lines on scripts/mod/modpost.c?  Is this some huge
> overhead that is unmaintainable?

You don't tell me why you want to do something as absurd and
incoherent as wanting users to load the modules easily and
automatically, then printing a warning about it even when user may not
have loaded it on his/her own, then taint the kernel when there is no
need to - I have repeatedly said it is very easy to see from the
module list for people to decide - not rocket science, definitely not
for developers. The whole TAINT drama is unnecessary.

Why would people run with even 24 more lines for something as absurd
as this when there is no need for the same?

Sure if you want to autoload modules on users back - do not complain
about it, do not make it official that it won't be supported since if
you do all your staging drivers are even more likely to stay there
like EXPERIMENTAL. (i.e. take out the printk , take out the TAINT) -
then it sounds less absurd.

Parag

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Stefan Richter]

Parag Warudkar wrote:
> I have repeatedly said it is very easy to see from the
> module list for people to decide - not rocket science, definitely not
> for developers. The whole TAINT drama is unnecessary.

It _is_ necessary.  I for one don't want to have to remember that driver 
foobar was in "staging" state in kernel 2.6.31-rc5, but not anymore in 
2.6.32-rc1.
-- 
Stefan Richter
-=====-==--- =--= ==-=-
http://arcgraph.de/sr/

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Parag Warudkar]

On Fri, Sep 26, 2008 at 2:36 PM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> It _is_ necessary.  I for one don't want to have to remember that driver
> foobar was in "staging" state in kernel 2.6.31-rc5, but not anymore in
> 2.6.32-rc1.

Just name the staging modules with _stg prefix like I said - easier to
spot _stg in the module list than decoding the taint. Whenever
(doubtful tone here) it graduates, remove the suffix. Driver modules
load automatically any way so the name change is not going to make a
difference.

It is nice to not have to change core kernel code and annoy users with
warnings for the staging crap even if it is just 24 lines or whatever
- if we can - and I don't see why we cannot. Staging, just like
crapping, has to be a totally isolated, zero side effect, zero
annoyance (to others) type thing :) So let's please get rid of that
taint and warning already :)

Parag

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Greg KH]

On Fri, Sep 26, 2008 at 04:11:49PM -0400, Parag Warudkar wrote:
> On Fri, Sep 26, 2008 at 2:36 PM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
> > It _is_ necessary.  I for one don't want to have to remember that driver
> > foobar was in "staging" state in kernel 2.6.31-rc5, but not anymore in
> > 2.6.32-rc1.
> 
> Just name the staging modules with _stg prefix like I said - easier to
> spot _stg in the module list than decoding the taint.

Um, it's the same, the taint is decoded automatically for you, no need
to strain any brain cells trying to figure it out :)

If people really want a prefix, sure, I have no objection, that's simple
to add.

> Whenever (doubtful tone here) it graduates, remove the suffix.

5 drivers "graduated" last release cycle, so it will happen.

> Driver modules load automatically any way so the name change is not
> going to make a difference.

Agreed.

> It is nice to not have to change core kernel code and annoy users with
> warnings for the staging crap even if it is just 24 lines or whatever
> - if we can - and I don't see why we cannot. Staging, just like
> crapping, has to be a totally isolated, zero side effect, zero
> annoyance (to others) type thing :) So let's please get rid of that
> taint and warning already :)

No, that was one of the requirements that came out of the discussions at
the kernel summit, I'm going to leave both the warning and the modalias
and taint flag there, sorry.

If you really don't like it, just never enable any of these modules,
you'll never be bothered by it.

thanks,

greg k-h

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Parag Warudkar]

On Fri, Sep 26, 2008 at 4:19 PM, Greg KH <gregkh@suse.de> wrote:

> If you really don't like it, just never enable any of these modules,
> you'll never be bothered by it.

So you are saying if a distro ships allmodconfig kernels or ships the
crap modules in the hope that people will find them useful and I have
one of the devices in my machine that I don't care about - I should
just let the crap module autoload and crash/taint my kernel or take
the special step of blacklisting all of them or build my own kernel -
as unreasonable as ever.

Or  are you saying distros should not build the crap modules - that
doesn't make sense since it will drastically reduce the usage and
delay the identification of problems until later.

If they weren't loaded automatically - it will simplify things a lot -
people with those devices willing to use those modules can forcibly
load the ones they require - that gives you your beloved TAINT and
avoids any core kernel changes.

No offense but I don't think is helping Greg. So I will stop.

Parag

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Greg KH]

On Fri, Sep 26, 2008 at 04:56:19PM -0400, Parag Warudkar wrote:
> On Fri, Sep 26, 2008 at 4:19 PM, Greg KH <gregkh@suse.de> wrote:
> 
> > If you really don't like it, just never enable any of these modules,
> > you'll never be bothered by it.
> 
> So you are saying if a distro ships allmodconfig kernels or ships the
> crap modules in the hope that people will find them useful and I have
> one of the devices in my machine that I don't care about - I should
> just let the crap module autoload and crash/taint my kernel or take
> the special step of blacklisting all of them or build my own kernel -
> as unreasonable as ever.

If your distro does this, then they will have their own rules in place
for supporting this.  Take it up with them if they decide to enable
this.

> Or  are you saying distros should not build the crap modules - that
> doesn't make sense since it will drastically reduce the usage and
> delay the identification of problems until later.

I'm saying distros need to evaluate this based on their own usage /
support model, just like they do so for all other config options.

As an example, for a distro that I know a bit about, I can see openSUSE
enabling this option and supporting these drivers the best that they
can, but for the SLES product line, which doesn't even load any modules
that are not fully L3 supported, these drivers would not be included.

As others have raised, the issue, I'll leave the driver names alone, it
would just confuse people even more if they changed, the modalias flag
is good enough to mark them by for now.

thanks,

greg k-h

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Leon Woestenberg]

Hello,

On Fri, Sep 26, 2008 at 10:19 PM, Greg KH <gregkh@suse.de> wrote:
> On Fri, Sep 26, 2008 at 04:11:49PM -0400, Parag Warudkar wrote:
>> On Fri, Sep 26, 2008 at 2:36 PM, Stefan Richter
>> <stefanr@s5r6.in-berlin.de> wrote:
>
> If you really don't like it, just never enable any of these modules,
> you'll never be bothered by it.
>
I would like new drivers for new devices to live into the wild.

Seriously, I think it's a good think to have new drivers lift along
with the kernel source distribution to get *much* wider attention,
testing, hacking and feedback.

I propose GREG_GOES_WILD and I will happily commit my
driver-in-progress to the kernel staging areas instead of to some
two-people-know-about-it-location.

Thanks for the effort, Greg,

Regards,
-- 
Leon

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Greg KH]

On Fri, Sep 26, 2008 at 11:00:17PM +0200, Leon Woestenberg wrote:
> Hello,
> 
> On Fri, Sep 26, 2008 at 10:19 PM, Greg KH <gregkh@suse.de> wrote:
> > On Fri, Sep 26, 2008 at 04:11:49PM -0400, Parag Warudkar wrote:
> >> On Fri, Sep 26, 2008 at 2:36 PM, Stefan Richter
> >> <stefanr@s5r6.in-berlin.de> wrote:
> >
> > If you really don't like it, just never enable any of these modules,
> > you'll never be bothered by it.
> >
> I would like new drivers for new devices to live into the wild.
> 
> Seriously, I think it's a good think to have new drivers lift along
> with the kernel source distribution to get *much* wider attention,
> testing, hacking and feedback.
> 
> I propose GREG_GOES_WILD and I will happily commit my
> driver-in-progress to the kernel staging areas instead of to some
> two-people-know-about-it-location.

Great, send them on over, I am already starting to queue them up (have 3
network drivers and one USB drivers in the tree, with more to come.)

thanks,

greg k-h

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Stefan Richter]

Parag Warudkar wrote:
> Just name the staging modules with _stg prefix like I said - easier to
> spot _stg in the module list than decoding the taint.
...
> It is nice to not have to change core kernel code and annoy users with
> warnings

Yes, let's annoy them with weird name changes instead.

(Seems you never communicate with users and never document something.)
-- 
Stefan Richter
-=====-==--- =--= ==-=-
http://arcgraph.de/sr/

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Parag Warudkar]

On Fri, Sep 26, 2008 at 4:39 PM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> Parag Warudkar wrote:
>>
>> Just name the staging modules with _stg prefix like I said - easier to
>> spot _stg in the module list than decoding the taint.
>
> ...
>>
>> It is nice to not have to change core kernel code and annoy users with
>> warnings
>
> Yes, let's annoy them with weird name changes instead.

So people now a days crave for documenting staging modules and also
get confused by the mixed use of driver_stg or driver? Come on.

The name changes hardly matter for auto loading staging modules and I
would be surprised if people document crap modules especially since
the stable ones are documented later if at all they end up being
documented.

Parag

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Stefan Richter]

Parag Warudkar wrote:
> On Fri, Sep 26, 2008 at 4:39 PM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
>> Parag Warudkar wrote:
>>> Just name the staging modules with _stg prefix like I said - easier to
>>> spot _stg in the module list than decoding the taint.
>> ...
>>> It is nice to not have to change core kernel code and annoy users with
>>> warnings
>> Yes, let's annoy them with weird name changes instead.
> 
> So people now a days crave for documenting staging modules and also
> get confused by the mixed use of driver_stg or driver? Come on.
> 
> The name changes hardly matter for auto loading staging modules

I continue to believe that you don't work with users.

> and I would be surprised if people document crap modules especially since
> the stable ones are documented later if at all they end up being
> documented.

Many of the staging drivers are already in active use; one or another 
even for years.  Since they are not as easy to use as mainline drivers, 
people discuss and document them.
-- 
Stefan Richter
-=====-==--- =--= ==-==
http://arcgraph.de/sr/

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Paul Mundt]

On Wed, Sep 24, 2008 at 10:59:03PM -0400, Parag Warudkar wrote:
> On Wed, Sep 24, 2008 at 10:06 PM, Greg KH <gregkh@suse.de> wrote:
> > No, this is much different from EXPERIMENTAL.  That flag is pretty much
> > useless right now.  This is for a temporary landing place for drivers
> > that are not good enough to be merged, yet are useful enough for some
> > people to use.
> 
> How? TAINT_EXPERIMENTAL (I'll stick to that, thanks :) and
> CONFIG_EXPERIMENTAL are no different - neither to users nor to
> developers. Here is why -
> Both try to do the same thing - let people use the drivers on their
> own risk (as if the stable ones are developer's risk - but let's keep
> it aside for the moment) and give developers a chance to keep the code
> in sync with mainline and improve it per user problem reports or
> generally make it better.
> 
Uhm.. not quite. As the one that proposed the flag in the first place,
perhaps it helps to cover the rationale (although Greg seems to have
mostly covered that already).

EXPERIMENTAL today is pretty damn meaningless. What it tends to mean in
practice is that somethings needs some more testing, someone wants to be
able to pull out the EXPERIMENTAL card when someone enables their option
and their kernel blows up, the option/feature hasn't been around in the
kernel for that long, or someone has just been too lazy to remove the
flag (this last one probably covers about 90% of in-tree cases today).
Stuff that is actively broken (in case of your kernel blowing up, not
building, etc.) tends to be shoved under BROKEN instead.

Case in point:

	$ find arch | grep _defconfig | wc -l
	336
	$ find arch | grep _defconfig | xargs grep 'CONFIG_EXPERIMENTAL=y' | wc -l
	324
	$ find arch | grep _defconfig | xargs grep 'CONFIG_BROKEN=y' | wc -l
	0

So given that, CONFIG_EXPERIMENTAL is something that's almost universally
enabled, and has precisely _zero_ meaning. As others have mentioned in
the past, it would be nice to try and audit each one of the EXPERIMENTAL
users and try to get things under control a bit, so we can get back to a
point where it actually means something, but we're definitely nowhere
near that point today.

Now, TAINT_CRAP (other options were TAINT_INCOMPETENT_VENDOR and
TAINT_GREG). This is something with a completely different meaning.
staging/ drivers are there because there are users for these devices, and
we actively want people looking at and cleaning up this code. As is
evident by other proprietary driver usage statistics, it's evident that
users will generally pick device functionality (whether perceived or
otherwise) over system stability quite a lot of the time.

The stuff in this directory is by no means ready to be merged with the
rest of the kernel, and is generally in pretty rough shape. While these
drivers are generally audited to make sure they are not actively hostile
to the system prior to being merged, they are still going to require
heavy rewriting before the bugs get shaken out and it actually looks like
kernel code. Vendor drivers will do such wonderful things as userspace
file I/O (when they aren't busy doing active NULL pointer dereferences)
from the kernel driver because that's what the windows driver did.
EXPERIMENTAL doesn't even begin to cover it, this is simply crap.

The other key difference is that even with experimental stuff in the
kernel, you will still get support, so it's not really a taintable
offense. Stuff in staging/ on the other hand while potentially not
actively hostile against the rest of the system, is still very much an
unknown, and therefore the only safe thing to do is to taint the system
and allow individual developers to make a choice regarding whether any
resulting oopses are worth looking at or not.

Part of the benefits of staging/ is catching all of the one-shot patches
that vendors toss out to meet their licensing requirements -- or so they
can slap a Linux-friendly logo on their shrinkwrap, where there are
already a good chunk of active users and folks interested in getting
things cleaned up, long after the vendor has bailed. Doing this sort of
work in-tree makes the most sense, as what's going on is immediately
visible, and you get a lot more people testing and working on the driver
in question. If we tried to force someone to make a sourceforge project
for every abandoned vendor driver, we'd end up with some sort of
wasteland of abandoned kernel code that looks something like, well,
sourceforge. Doing this sort of work out-of-tree just isn't worth it. The
staging/ tree has been doing well out-of-tree to date, but these sorts of
things aren't going to get any real momentum without being integrated,
with the users/developers and vendors forced to actually deal with the
problem.

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Randy Dunlap]

On Thu, 25 Sep 2008 14:27:26 +0900 Paul Mundt wrote:

> On Wed, Sep 24, 2008 at 10:59:03PM -0400, Parag Warudkar wrote:
> > On Wed, Sep 24, 2008 at 10:06 PM, Greg KH <gregkh@suse.de> wrote:
> > > No, this is much different from EXPERIMENTAL.  That flag is pretty much
> > > useless right now.  This is for a temporary landing place for drivers
> > > that are not good enough to be merged, yet are useful enough for some
> > > people to use.
> > 
> > How? TAINT_EXPERIMENTAL (I'll stick to that, thanks :) and
> > CONFIG_EXPERIMENTAL are no different - neither to users nor to
> > developers. Here is why -
> > Both try to do the same thing - let people use the drivers on their
> > own risk (as if the stable ones are developer's risk - but let's keep
> > it aside for the moment) and give developers a chance to keep the code
> > in sync with mainline and improve it per user problem reports or
> > generally make it better.
> > 
> Uhm.. not quite. As the one that proposed the flag in the first place,
> perhaps it helps to cover the rationale (although Greg seems to have
> mostly covered that already).
> 
> EXPERIMENTAL today is pretty damn meaningless. What it tends to mean in

then it would be better if Greg/someone cleaned up the current tree's
problems instead of introducing more CRAP under a different name.
Oh well, his mind is already made up and I know how difficult it is to
change it.


> practice is that somethings needs some more testing, someone wants to be
> able to pull out the EXPERIMENTAL card when someone enables their option
> and their kernel blows up, the option/feature hasn't been around in the
> kernel for that long, or someone has just been too lazy to remove the
> flag (this last one probably covers about 90% of in-tree cases today).
> Stuff that is actively broken (in case of your kernel blowing up, not
> building, etc.) tends to be shoved under BROKEN instead.
> 
> Case in point:
> 
> 	$ find arch | grep _defconfig | wc -l
> 	336
> 	$ find arch | grep _defconfig | xargs grep 'CONFIG_EXPERIMENTAL=y' | wc -l
> 	324
> 	$ find arch | grep _defconfig | xargs grep 'CONFIG_BROKEN=y' | wc -l
> 	0
> 
> So given that, CONFIG_EXPERIMENTAL is something that's almost universally
> enabled, and has precisely _zero_ meaning. As others have mentioned in
> the past, it would be nice to try and audit each one of the EXPERIMENTAL
> users and try to get things under control a bit, so we can get back to a
> point where it actually means something, but we're definitely nowhere
> near that point today.
> 
> Now, TAINT_CRAP (other options were TAINT_INCOMPETENT_VENDOR and
> TAINT_GREG). This is something with a completely different meaning.
> staging/ drivers are there because there are users for these devices, and
> we actively want people looking at and cleaning up this code. As is
> evident by other proprietary driver usage statistics, it's evident that
> users will generally pick device functionality (whether perceived or
> otherwise) over system stability quite a lot of the time.
> 
> The stuff in this directory is by no means ready to be merged with the
> rest of the kernel, and is generally in pretty rough shape. While these
> drivers are generally audited to make sure they are not actively hostile
> to the system prior to being merged, they are still going to require
> heavy rewriting before the bugs get shaken out and it actually looks like
> kernel code. Vendor drivers will do such wonderful things as userspace
> file I/O (when they aren't busy doing active NULL pointer dereferences)
> from the kernel driver because that's what the windows driver did.
> EXPERIMENTAL doesn't even begin to cover it, this is simply crap.
> 
> The other key difference is that even with experimental stuff in the
> kernel, you will still get support, so it's not really a taintable
> offense. Stuff in staging/ on the other hand while potentially not
> actively hostile against the rest of the system, is still very much an
> unknown, and therefore the only safe thing to do is to taint the system
> and allow individual developers to make a choice regarding whether any
> resulting oopses are worth looking at or not.
> 
> Part of the benefits of staging/ is catching all of the one-shot patches
> that vendors toss out to meet their licensing requirements -- or so they
> can slap a Linux-friendly logo on their shrinkwrap, where there are
> already a good chunk of active users and folks interested in getting
> things cleaned up, long after the vendor has bailed. Doing this sort of
> work in-tree makes the most sense, as what's going on is immediately
> visible, and you get a lot more people testing and working on the driver
> in question. If we tried to force someone to make a sourceforge project
> for every abandoned vendor driver, we'd end up with some sort of
> wasteland of abandoned kernel code that looks something like, well,
> sourceforge. Doing this sort of work out-of-tree just isn't worth it. The
> staging/ tree has been doing well out-of-tree to date, but these sorts of
> things aren't going to get any real momentum without being integrated,
> with the users/developers and vendors forced to actually deal with the
> problem.
> --

---
~Randy

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Randy Dunlap]

On Thu, 25 Sep 2008 07:49:23 -0700 Randy Dunlap wrote:

> On Thu, 25 Sep 2008 14:27:26 +0900 Paul Mundt wrote:
> 
> > On Wed, Sep 24, 2008 at 10:59:03PM -0400, Parag Warudkar wrote:
> > > On Wed, Sep 24, 2008 at 10:06 PM, Greg KH <gregkh@suse.de> wrote:
> > > > No, this is much different from EXPERIMENTAL.  That flag is pretty much
> > > > useless right now.  This is for a temporary landing place for drivers
> > > > that are not good enough to be merged, yet are useful enough for some
> > > > people to use.
> > > 
> > > How? TAINT_EXPERIMENTAL (I'll stick to that, thanks :) and
> > > CONFIG_EXPERIMENTAL are no different - neither to users nor to
> > > developers. Here is why -
> > > Both try to do the same thing - let people use the drivers on their
> > > own risk (as if the stable ones are developer's risk - but let's keep
> > > it aside for the moment) and give developers a chance to keep the code
> > > in sync with mainline and improve it per user problem reports or
> > > generally make it better.
> > > 
> > Uhm.. not quite. As the one that proposed the flag in the first place,
> > perhaps it helps to cover the rationale (although Greg seems to have
> > mostly covered that already).
> > 
> > EXPERIMENTAL today is pretty damn meaningless. What it tends to mean in
> 
> then it would be better if Greg/someone cleaned up the current tree's
> problems instead of introducing more CRAP under a different name.
> Oh well, his mind is already made up and I know how difficult it is to
> change it.

I shouldn't have said that last sentence.  I apologize to Greg.

ISTM that the real problems are (a) it's easier to introduce new staging/crap
than it is to fix EXPERIMENTAL and (b) no one wants to try to fix EXPERIMENTAL.


---
~Randy

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Greg KH]

On Thu, Sep 25, 2008 at 10:53:20AM -0700, Randy Dunlap wrote:
> On Thu, 25 Sep 2008 07:49:23 -0700 Randy Dunlap wrote:
> 
> > On Thu, 25 Sep 2008 14:27:26 +0900 Paul Mundt wrote:
> > 
> > > On Wed, Sep 24, 2008 at 10:59:03PM -0400, Parag Warudkar wrote:
> > > > On Wed, Sep 24, 2008 at 10:06 PM, Greg KH <gregkh@suse.de> wrote:
> > > > > No, this is much different from EXPERIMENTAL.  That flag is pretty much
> > > > > useless right now.  This is for a temporary landing place for drivers
> > > > > that are not good enough to be merged, yet are useful enough for some
> > > > > people to use.
> > > > 
> > > > How? TAINT_EXPERIMENTAL (I'll stick to that, thanks :) and
> > > > CONFIG_EXPERIMENTAL are no different - neither to users nor to
> > > > developers. Here is why -
> > > > Both try to do the same thing - let people use the drivers on their
> > > > own risk (as if the stable ones are developer's risk - but let's keep
> > > > it aside for the moment) and give developers a chance to keep the code
> > > > in sync with mainline and improve it per user problem reports or
> > > > generally make it better.
> > > > 
> > > Uhm.. not quite. As the one that proposed the flag in the first place,
> > > perhaps it helps to cover the rationale (although Greg seems to have
> > > mostly covered that already).
> > > 
> > > EXPERIMENTAL today is pretty damn meaningless. What it tends to mean in
> > 
> > then it would be better if Greg/someone cleaned up the current tree's
> > problems instead of introducing more CRAP under a different name.
> > Oh well, his mind is already made up and I know how difficult it is to
> > change it.
> 
> I shouldn't have said that last sentence.  I apologize to Greg.

Heh, no problem, normally my problem is that I change my mind too often,
or so my kids complain :)

> ISTM that the real problems are (a) it's easier to introduce new staging/crap
> than it is to fix EXPERIMENTAL and (b) no one wants to try to fix EXPERIMENTAL.

The whole EXPERIMENTAL issue hasn't come up in years, I'm supprised that
people even consider it a valid option these days.

I'm all for fixing it up, but as Paul so well described, the code I'm
talking about is WAY worse than a mere "experimental" marking, it needs
to be explicitly pointed out that this is not even up to that level at
all.

And as was also pointed out, the EXPERIMENTAL marking cleanup is totally
orthogonal to the main goal here, and that is getting code into the tree
that is not up to our "normal" merge quality levels, in order to get a
wider audience of users and developers working on it, and using it.

Hey, if people want me to name it TAINT_GREGKH, I can do that, I thought
I was being nice by picking TAINT_CRAP...

thanks,

greg k-h

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Randy Dunlap]

>> ISTM that the real problems are (a) it's easier to introduce new staging/crap
>> than it is to fix EXPERIMENTAL and (b) no one wants to try to fix EXPERIMENTAL.
> 
> The whole EXPERIMENTAL issue hasn't come up in years, I'm supprised that
> people even consider it a valid option these days.
> 
> I'm all for fixing it up, but as Paul so well described, the code I'm
> talking about is WAY worse than a mere "experimental" marking, it needs
> to be explicitly pointed out that this is not even up to that level at
> all.
> 
> And as was also pointed out, the EXPERIMENTAL marking cleanup is totally
> orthogonal to the main goal here, and that is getting code into the tree
> that is not up to our "normal" merge quality levels, in order to get a
> wider audience of users and developers working on it, and using it.
> 
> Hey, if people want me to name it TAINT_GREGKH, I can do that, I thought
> I was being nice by picking TAINT_CRAP...

I don't disagree with the CRAP name... fwiw.
I think that we have enough quality problems without adding crap.

-- 
~Randy

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Stefan Richter]

Randy Dunlap wrote:
>>> ISTM that the real problems are (a) it's easier to introduce new staging/crap
>>> than it is to fix EXPERIMENTAL and (b) no one wants to try to fix EXPERIMENTAL.
...
> I don't disagree with the CRAP name... fwiw.
> I think that we have enough quality problems without adding crap.

True.  OTOH many if not most of the -staging drivers are ones which are 
already in use.  Their users already deal with whatever quality problems 
these drivers have, in addition to having to fight with the installation 
hassles that are inherent to out-of-tree drivers.
-- 
Stefan Richter
-=====-==--- =--= ==--=
http://arcgraph.de/sr/

config_experimental was Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Pavel Machek]

Hi!

> > > > How? TAINT_EXPERIMENTAL (I'll stick to that, thanks :) and
> > > > CONFIG_EXPERIMENTAL are no different - neither to users nor to
> > > > developers. Here is why -
> > > > Both try to do the same thing - let people use the drivers on their
> > > > own risk (as if the stable ones are developer's risk - but let's keep
> > > > it aside for the moment) and give developers a chance to keep the code
> > > > in sync with mainline and improve it per user problem reports or
> > > > generally make it better.
> > > > 
> > > Uhm.. not quite. As the one that proposed the flag in the first place,
> > > perhaps it helps to cover the rationale (although Greg seems to have
> > > mostly covered that already).
> > > 
> > > EXPERIMENTAL today is pretty damn meaningless. What it tends to mean in
> > 
> > then it would be better if Greg/someone cleaned up the current tree's
> > problems instead of introducing more CRAP under a different name.
> > Oh well, his mind is already made up and I know how difficult it is to
> > change it.
> 
> I shouldn't have said that last sentence.  I apologize to Greg.
> 
> ISTM that the real problems are (a) it's easier to introduce new staging/crap
> than it is to fix EXPERIMENTAL and (b) no one wants to try to fix EXPERIMENTAL.
> 

I do believe that staging != experimental.

experimental == 'good enough code architecture-wise, needs more
testing, coding style is ok'

staging == 'don't look at this after lunch' (at least parts are bad).

Now... I guess someone could go over supported drivers in enterprise
distro, and remove experimental from all of them in mainline...?
Distros pay some attetion to what code they are willing to support...

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Adrian Bunk]

On Wed, Sep 24, 2008 at 04:00:54PM -0700, Greg KH wrote:
> As we all discussed at the Kernel Summit this past week, I said I would
> create a drivers/staging directory and start throwing lots of drivers
> that are not of "mergable" status into it.
>...
> The 3rd patch creates the drivers/staging/ directory and Kconfig entries
> and adds it to the build system.
> 
> The 4th patch is an example of a driver that would go into this
> directory, along with a driver_name.README file detailing what needs to
> be done to this driver for cleanup/fixing, and who to contact about it.
> It's also in such bad shape it doesn't even build against the kernel
> kernel :)
> 
> (I'll fix that up before submitting, all drivers should at least build
> properly...)
> 
> So, does this all look good to everyone?  Any questions/issues?
> 
> Oh, I guess I should add a MAINTAINER entry for this section of the
> kernel, so to paraphrase Linus, I now get to be known as the "Maintainer
> of Crap".

Sorry for being late in the discussion, I'm currently catching up with 
my email backlog.

What does that mean in practice for kernel development?

Will breaking crap be considered OK?

As an example, let's assume some crap drivers use the BKL in a way that 
it might require the BKL in some core part of the kernel. Will the 
person removing the BKL in the core part of the kernel be forced to fix 
the locking of all possibly affected crap drivers no matter how broken 
and undocumented it is, or can he simply ignore the crap and leave the 
fixing to the Maintainer of Crap?

> thanks,
> 
> greg k-h

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Greg KH]

On Fri, Oct 10, 2008 at 12:01:37AM +0300, Adrian Bunk wrote:
> On Wed, Sep 24, 2008 at 04:00:54PM -0700, Greg KH wrote:
> > As we all discussed at the Kernel Summit this past week, I said I would
> > create a drivers/staging directory and start throwing lots of drivers
> > that are not of "mergable" status into it.
> >...
> > The 3rd patch creates the drivers/staging/ directory and Kconfig entries
> > and adds it to the build system.
> > 
> > The 4th patch is an example of a driver that would go into this
> > directory, along with a driver_name.README file detailing what needs to
> > be done to this driver for cleanup/fixing, and who to contact about it.
> > It's also in such bad shape it doesn't even build against the kernel
> > kernel :)
> > 
> > (I'll fix that up before submitting, all drivers should at least build
> > properly...)
> > 
> > So, does this all look good to everyone?  Any questions/issues?
> > 
> > Oh, I guess I should add a MAINTAINER entry for this section of the
> > kernel, so to paraphrase Linus, I now get to be known as the "Maintainer
> > of Crap".
> 
> Sorry for being late in the discussion, I'm currently catching up with 
> my email backlog.
> 
> What does that mean in practice for kernel development?

Nothing.

> Will breaking crap be considered OK?

Yes.

> As an example, let's assume some crap drivers use the BKL in a way that 
> it might require the BKL in some core part of the kernel. Will the 
> person removing the BKL in the core part of the kernel be forced to fix 
> the locking of all possibly affected crap drivers no matter how broken 
> and undocumented it is, or can he simply ignore the crap and leave the 
> fixing to the Maintainer of Crap?

He can ignore the crap and leave the fixing to the Maintainer of Crap.

Although a short note to the Maintainer of Crap about the crap that
needs fixing in the tree of crap, would be polite, it is not required.

thanks,

greg "surrounded by crap" k-h

Re: [patch 00/04] RFC: Staging tree (drivers/staging)

[Andrew Morton]

On Fri, 10 Oct 2008 00:01:37 +0300
Adrian Bunk <bunk@kernel.org> wrote:

> On Wed, Sep 24, 2008 at 04:00:54PM -0700, Greg KH wrote:
> > As we all discussed at the Kernel Summit this past week, I said I would
> > create a drivers/staging directory and start throwing lots of drivers
> > that are not of "mergable" status into it.
> >...
> > The 3rd patch creates the drivers/staging/ directory and Kconfig entries
> > and adds it to the build system.
> > 
> > The 4th patch is an example of a driver that would go into this
> > directory, along with a driver_name.README file detailing what needs to
> > be done to this driver for cleanup/fixing, and who to contact about it.
> > It's also in such bad shape it doesn't even build against the kernel
> > kernel :)
> > 
> > (I'll fix that up before submitting, all drivers should at least build
> > properly...)
> > 
> > So, does this all look good to everyone?  Any questions/issues?
> > 
> > Oh, I guess I should add a MAINTAINER entry for this section of the
> > kernel, so to paraphrase Linus, I now get to be known as the "Maintainer
> > of Crap".
> 
> Sorry for being late in the discussion, I'm currently catching up with 
> my email backlog.
> 
> What does that mean in practice for kernel development?
> 
> Will breaking crap be considered OK?
> 
> As an example, let's assume some crap drivers use the BKL in a way that 
> it might require the BKL in some core part of the kernel. Will the 
> person removing the BKL in the core part of the kernel be forced to fix 
> the locking of all possibly affected crap drivers no matter how broken 
> and undocumented it is, or can he simply ignore the crap and leave the 
> fixing to the Maintainer of Crap?
> 

<collapses in a hysterical seizure>

Every development tree right now will go out and breezily break random
other development trees with nary a care in the world.

What difference does one more tree make?