[patch 00/13] devtmpfs patches

[patch 00/13] devtmpfs patches

[Greg KH]

Here's the latest version of the devtmpfs patch, broken up into 13
different patches to make it easier to review and merge properly.

This series does the following:
  - creates a new callback within the driver core to allow drivers and
    subsystems to provide a name for their subsystem to properly reflect
    what userspace should use for their device nodes.  This allows for
    things like the sound/ and input/ subdirectories to be properly told
    to userspace.  Note these names and subdirectories are the ones that
    have been used for years, and are standardized across all
    distributions and synced up with the LANANA naming scheme which is
    specified by LSB.  We aren't creating anything new here.
  - fills in the callbacks by the various subsystems that need to define
    it, including the misc device layer.  This is the majority of the
    patches in the series.
  - adds the devtmpfs core code.  Description of what this is, why it is
    needed, and how it works is within this patch.

All of these patches have been tested for a number of weeks now in
SuSE's kernel trees and have proved to increase boot time a measurable
ammount (a few seconds at the very least) on both traditional systems
(servers / desktops) as well as on netbooks using a non-SuSE based
userspace infrastructure.

This feature also allows rescue systems to work properly by allowing
systems to boot into /bin/bash with full access to all of their device
nodes.  It is also a big win on embedded systems with no local users yet
they need to provide dynamic names as their hardware configuration can
be changed by external forces.

All of the previous objections to this patch series seems to have been
properly addressed, but as always, comments are welcome, just make them
substantial please :)

These patches are now in the driver-core git tree of quilt patches.

thanks,

greg k-h

[patch 01/13] Driver Core: add nodename callbacks

[Greg KH]

[-- Attachment #1: driver-core-add-nodename-callbacks.patch --]
[-- Type: text/plain, Size: 3562 bytes --]

From: Kay Sievers <kay.sievers@vrfy.org>

This adds the nodename callback for struct class, struct device_type and
struct device, to allow drivers to send userspace hints on the device
name and subdirectory that should be used for it.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/base/core.c    |   51 ++++++++++++++++++++++++++++++++++++++++++++++++-
 include/linux/device.h |    4 +++
 2 files changed, 54 insertions(+), 1 deletion(-)

--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -161,10 +161,18 @@ static int dev_uevent(struct kset *kset,
 	struct device *dev = to_dev(kobj);
 	int retval = 0;
 
-	/* add the major/minor if present */
+	/* add device node properties if present */
 	if (MAJOR(dev->devt)) {
+		const char *tmp;
+		const char *name;
+
 		add_uevent_var(env, "MAJOR=%u", MAJOR(dev->devt));
 		add_uevent_var(env, "MINOR=%u", MINOR(dev->devt));
+		name = device_get_nodename(dev, &tmp);
+		if (name) {
+			add_uevent_var(env, "DEVNAME=%s", name);
+			kfree(tmp);
+		}
 	}
 
 	if (dev->type && dev->type->name)
@@ -1125,6 +1133,47 @@ static struct device *next_device(struct
 }
 
 /**
+ * device_get_nodename - path of device node file
+ * @dev: device
+ * @tmp: possibly allocated string
+ *
+ * Return the relative path of a possible device node.
+ * Non-default names may need to allocate a memory to compose
+ * a name. This memory is returned in tmp and needs to be
+ * freed by the caller.
+ */
+const char *device_get_nodename(struct device *dev, const char **tmp)
+{
+	char *s;
+
+	*tmp = NULL;
+
+	/* the device type may provide a specific name */
+	if (dev->type && dev->type->nodename)
+		*tmp = dev->type->nodename(dev);
+	if (*tmp)
+		return *tmp;
+
+	/* the class may provide a specific name */
+	if (dev->class && dev->class->nodename)
+		*tmp = dev->class->nodename(dev);
+	if (*tmp)
+		return *tmp;
+
+	/* return name without allocation, tmp == NULL */
+	if (strchr(dev_name(dev), '!') == NULL)
+		return dev_name(dev);
+
+	/* replace '!' in the name with '/' */
+	*tmp = kstrdup(dev_name(dev), GFP_KERNEL);
+	if (!*tmp)
+		return NULL;
+	while ((s = strchr(*tmp, '!')))
+		s[0] = '/';
+	return *tmp;
+}
+
+/**
  * device_for_each_child - device child iterator.
  * @parent: parent struct device.
  * @data: data for the callback.
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -196,6 +196,7 @@ struct class {
 	struct kobject			*dev_kobj;
 
 	int (*dev_uevent)(struct device *dev, struct kobj_uevent_env *env);
+	char *(*nodename)(struct device *dev);
 
 	void (*class_release)(struct class *class);
 	void (*dev_release)(struct device *dev);
@@ -291,6 +292,7 @@ struct device_type {
 	const char *name;
 	struct attribute_group **groups;
 	int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
+	char *(*nodename)(struct device *dev);
 	void (*release)(struct device *dev);
 
 	int (*suspend)(struct device *dev, pm_message_t state);
@@ -371,6 +373,7 @@ struct device_dma_parameters {
 
 struct device {
 	struct device		*parent;
+	char *(*nodename)(struct device *dev);
 
 	struct device_private	*p;
 
@@ -493,6 +496,7 @@ extern struct device *device_find_child(
 extern int device_rename(struct device *dev, char *new_name);
 extern int device_move(struct device *dev, struct device *new_parent,
 		       enum dpm_order dpm_order);
+extern const char *device_get_nodename(struct device *dev, const char **tmp);
 
 /*
  * Root device objects for grouping under /sys/devices

Re: [patch 01/13] Driver Core: add nodename callbacks

[Stephen Rothwell]

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

Hi Greg, Kay,

On Sat, 09 May 2009 07:26:02 -0700 Greg KH <greg@kroah.com> wrote:
>
> +++ b/include/linux/device.h
>  struct device {
>  	struct device		*parent;
> +	char *(*nodename)(struct device *dev);

Just wondering what this callback is for.  I didn't look really hard, but
couldn't find it used anywhere.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [patch 01/13] Driver Core: add nodename callbacks

[Kay Sievers]

On Sun, May 10, 2009 at 14:52, Stephen Rothwell <sfr@canb.auug.org.au> wrote:

>> +++ b/include/linux/device.h
>>  struct device {
>>       struct device           *parent;
>> +     char *(*nodename)(struct device *dev);
>
> Just wondering what this callback is for.  I didn't look really hard, but
> couldn't find it used anywhere.

You are right, that seems like a left-over which did not get used, and
should be removed from the patch.

Thanks a lot for checking,
Kay

Re: [patch 01/13] Driver Core: add nodename callbacks

[Greg KH]

On Sun, May 10, 2009 at 03:19:46PM +0200, Kay Sievers wrote:
> On Sun, May 10, 2009 at 14:52, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> >> +++ b/include/linux/device.h
> >>  struct device {
> >>       struct device           *parent;
> >> +     char *(*nodename)(struct device *dev);
> >
> > Just wondering what this callback is for.  I didn't look really hard, but
> > couldn't find it used anywhere.
> 
> You are right, that seems like a left-over which did not get used, and
> should be removed from the patch.

I've now removed it, thanks Stephen for finding this.

greg k-h

[patch 02/13] Driver Core: misc: add nodename support for misc devices.

[Greg KH]

[-- Attachment #1: driver-core-misc-add-nodename-support-for-misc-devices.patch --]
[-- Type: text/plain, Size: 3335 bytes --]

From: Kay Sievers <kay.sievers@vrfy.org>

This adds support for misc devices to report their requested nodename to
userspace.  It also updates a number of misc drivers to provide the
needed subdirectory and device name to be used for them.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kernel/microcode_core.c |    1 +
 drivers/char/hw_random/core.c    |    1 +
 drivers/char/misc.c              |   15 ++++++++++++---
 drivers/md/dm-ioctl.c            |    1 +
 drivers/net/tun.c                |    1 +
 include/linux/miscdevice.h       |    1 +
 6 files changed, 17 insertions(+), 3 deletions(-)

--- a/arch/x86/kernel/microcode_core.c
+++ b/arch/x86/kernel/microcode_core.c
@@ -173,6 +173,7 @@ static const struct file_operations micr
 static struct miscdevice microcode_dev = {
 	.minor		= MICROCODE_MINOR,
 	.name		= "microcode",
+	.devnode	= "cpu/microcode",
 	.fops		= &microcode_fops,
 };
 
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -153,6 +153,7 @@ static const struct file_operations rng_
 static struct miscdevice rng_miscdev = {
 	.minor		= RNG_MISCDEV_MINOR,
 	.name		= RNG_MODULE_NAME,
+	.devnode	= "hwrng",
 	.fops		= &rng_chrdev_ops,
 };
 
--- a/drivers/char/misc.c
+++ b/drivers/char/misc.c
@@ -168,7 +168,6 @@ static const struct file_operations misc
 	.open		= misc_open,
 };
 
-
 /**
  *	misc_register	-	register a miscellaneous device
  *	@misc: device structure
@@ -217,8 +216,8 @@ int misc_register(struct miscdevice * mi
 		misc_minors[misc->minor >> 3] |= 1 << (misc->minor & 7);
 	dev = MKDEV(MISC_MAJOR, misc->minor);
 
-	misc->this_device = device_create(misc_class, misc->parent, dev, NULL,
-					  "%s", misc->name);
+	misc->this_device = device_create(misc_class, misc->parent, dev,
+					  misc, "%s", misc->name);
 	if (IS_ERR(misc->this_device)) {
 		err = PTR_ERR(misc->this_device);
 		goto out;
@@ -264,6 +263,15 @@ int misc_deregister(struct miscdevice *m
 EXPORT_SYMBOL(misc_register);
 EXPORT_SYMBOL(misc_deregister);
 
+static char *misc_nodename(struct device *dev)
+{
+	struct miscdevice *c = dev_get_drvdata(dev);
+
+	if (c->devnode)
+		return kstrdup(c->devnode, GFP_KERNEL);
+	return NULL;
+}
+
 static int __init misc_init(void)
 {
 	int err;
@@ -279,6 +287,7 @@ static int __init misc_init(void)
 	err = -EIO;
 	if (register_chrdev(MISC_MAJOR,"misc",&misc_fops))
 		goto fail_printk;
+	misc_class->nodename = misc_nodename;
 	return 0;
 
 fail_printk:
--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -1513,6 +1513,7 @@ static const struct file_operations _ctl
 static struct miscdevice _dm_misc = {
 	.minor 		= MISC_DYNAMIC_MINOR,
 	.name  		= DM_NAME,
+	.devnode	= "mapper/control",
 	.fops  		= &_ctl_fops
 };
 
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1318,6 +1318,7 @@ static const struct file_operations tun_
 static struct miscdevice tun_miscdev = {
 	.minor = TUN_MINOR,
 	.name = "tun",
+	.devnode = "net/tun",
 	.fops = &tun_fops,
 };
 
--- a/include/linux/miscdevice.h
+++ b/include/linux/miscdevice.h
@@ -41,6 +41,7 @@ struct miscdevice  {
 	struct list_head list;
 	struct device *parent;
 	struct device *this_device;
+	const char *devnode;
 };
 
 extern int misc_register(struct miscdevice * misc);

Re: [patch 02/13] Driver Core: misc: add nodename support for misc devices.

[Pavel Machek]

On Sat 2009-05-09 07:26:03, Greg KH wrote:
> From: Kay Sievers <kay.sievers@vrfy.org>
> 
> This adds support for misc devices to report their requested nodename to
> userspace.  It also updates a number of misc drivers to provide the
> needed subdirectory and device name to be used for them.
> 
> Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
> Signed-off-by: Jan Blunck <jblunck@suse.de>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Maybe it would be better to assign stable minor/major numbers to those
devices instead? minor/major number space is pretty big these days...

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

Re: [patch 02/13] Driver Core: misc: add nodename support for misc devices.

[Greg KH]

On Fri, May 15, 2009 at 09:58:56PM +0200, Pavel Machek wrote:
> On Sat 2009-05-09 07:26:03, Greg KH wrote:
> > From: Kay Sievers <kay.sievers@vrfy.org>
> > 
> > This adds support for misc devices to report their requested nodename to
> > userspace.  It also updates a number of misc drivers to provide the
> > needed subdirectory and device name to be used for them.
> > 
> > Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
> > Signed-off-by: Jan Blunck <jblunck@suse.de>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> Maybe it would be better to assign stable minor/major numbers to those
> devices instead? minor/major number space is pretty big these days...

That's up to the individual misc driver authors.  Lots of them use the
dynamic option, so it's not like we can just ignore this very common
feature.

thanks,

greg k-h

Re: [patch 02/13] Driver Core: misc: add nodename support for misc devices.

[Pavel Machek]

On Mon 2009-05-18 07:34:06, Greg KH wrote:
> On Fri, May 15, 2009 at 09:58:56PM +0200, Pavel Machek wrote:
> > On Sat 2009-05-09 07:26:03, Greg KH wrote:
> > > From: Kay Sievers <kay.sievers@vrfy.org>
> > > 
> > > This adds support for misc devices to report their requested nodename to
> > > userspace.  It also updates a number of misc drivers to provide the
> > > needed subdirectory and device name to be used for them.
> > > 
> > > Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
> > > Signed-off-by: Jan Blunck <jblunck@suse.de>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > 
> > Maybe it would be better to assign stable minor/major numbers to those
> > devices instead? minor/major number space is pretty big these days...
> 
> That's up to the individual misc driver authors.  Lots of them use the
> dynamic option, so it's not like we can just ignore this very common
> feature.

Well, you are willing to submit device names for individual drivers,
so... 

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

Re: [patch 02/13] Driver Core: misc: add nodename support for misc devices.

[Alan Cox]

On Fri, 15 May 2009 21:58:56 +0200
Pavel Machek <pavel@ucw.cz> wrote:

> On Sat 2009-05-09 07:26:03, Greg KH wrote:
> > From: Kay Sievers <kay.sievers@vrfy.org>
> > 
> > This adds support for misc devices to report their requested nodename to
> > userspace.  It also updates a number of misc drivers to provide the
> > needed subdirectory and device name to be used for them.
> > 
> > Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
> > Signed-off-by: Jan Blunck <jblunck@suse.de>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> Maybe it would be better to assign stable minor/major numbers to those
> devices instead? minor/major number space is pretty big these days...

More to the point we already have /proc/misc

[patch 03/13] Driver Core: usb: add nodename support for usb drivers.

[Greg KH]

[-- Attachment #1: driver-core-usb-add-nodename-support-for-usb-drivers.patch --]
[-- Type: text/plain, Size: 5791 bytes --]

From: Kay Sievers <kay.sievers@vrfy.org>

This adds support for USB drivers to report their requested nodename to
userspace.  It also updates a number of USB drivers to provide the
needed subdirectory and device name to be used for them.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/hid/usbhid/hiddev.c     |    7 ++++++-
 drivers/media/video/dabusb.c    |    6 ++++++
 drivers/usb/class/usblp.c       |    6 ++++++
 drivers/usb/core/file.c         |   13 ++++++++++++-
 drivers/usb/core/usb.c          |   11 +++++++++++
 drivers/usb/misc/iowarrior.c    |    6 ++++++
 drivers/usb/misc/legousbtower.c |    6 ++++++
 include/linux/usb.h             |    3 +++
 8 files changed, 56 insertions(+), 2 deletions(-)

--- a/drivers/hid/usbhid/hiddev.c
+++ b/drivers/hid/usbhid/hiddev.c
@@ -850,8 +850,14 @@ static const struct file_operations hidd
 #endif
 };
 
+static char *hiddev_nodename(struct device *dev)
+{
+	return kasprintf(GFP_KERNEL, "usb/%s", dev_name(dev));
+}
+
 static struct usb_class_driver hiddev_class = {
 	.name =		"hiddev%d",
+	.nodename =	hiddev_nodename,
 	.fops =		&hiddev_fops,
 	.minor_base =	HIDDEV_MINOR_BASE,
 };
@@ -955,7 +961,6 @@ static int hiddev_usbd_probe(struct usb_
 	return -ENODEV;
 }
 
-
 static /* const */ struct usb_driver hiddev_driver = {
 	.name =		"hiddev",
 	.probe =	hiddev_usbd_probe,
--- a/drivers/media/video/dabusb.c
+++ b/drivers/media/video/dabusb.c
@@ -747,8 +747,14 @@ static const struct file_operations dabu
 	.release =	dabusb_release,
 };
 
+static char *dabusb_nodename(struct device *dev)
+{
+	return kasprintf(GFP_KERNEL, "usb/%s", dev_name(dev));
+}
+
 static struct usb_class_driver dabusb_class = {
 	.name =		"dabusb%d",
+	.nodename =	dabusb_nodename,
 	.fops =		&dabusb_fops,
 	.minor_base =	DABUSB_MINOR,
 };
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -1057,8 +1057,14 @@ static const struct file_operations usbl
 	.release =	usblp_release,
 };
 
+static char *usblp_nodename(struct device *dev)
+{
+	return kasprintf(GFP_KERNEL, "usb/%s", dev_name(dev));
+}
+
 static struct usb_class_driver usblp_class = {
 	.name =		"lp%d",
+	.nodename =	usblp_nodename,
 	.fops =		&usblp_fops,
 	.minor_base =	USBLP_MINOR_BASE,
 };
--- a/drivers/usb/core/file.c
+++ b/drivers/usb/core/file.c
@@ -67,6 +67,16 @@ static struct usb_class {
 	struct class *class;
 } *usb_class;
 
+static char *usb_nodename(struct device *dev)
+{
+	struct usb_class_driver *drv;
+
+	drv = dev_get_drvdata(dev);
+	if (!drv || !drv->nodename)
+		return NULL;
+	return drv->nodename(dev);
+}
+
 static int init_usb_class(void)
 {
 	int result = 0;
@@ -90,6 +100,7 @@ static int init_usb_class(void)
 		kfree(usb_class);
 		usb_class = NULL;
 	}
+	usb_class->class->nodename = usb_nodename;
 
 exit:
 	return result;
@@ -198,7 +209,7 @@ int usb_register_dev(struct usb_interfac
 	else
 		temp = name;
 	intf->usb_dev = device_create(usb_class->class, &intf->dev,
-				      MKDEV(USB_MAJOR, minor), NULL,
+				      MKDEV(USB_MAJOR, minor), class_driver,
 				      "%s", temp);
 	if (IS_ERR(intf->usb_dev)) {
 		down_write(&minor_rwsem);
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -305,10 +305,21 @@ static struct dev_pm_ops usb_device_pm_o
 
 #endif	/* CONFIG_PM */
 
+
+static char *usb_nodename(struct device *dev)
+{
+	struct usb_device *usb_dev;
+
+	usb_dev = to_usb_device(dev);
+	return kasprintf(GFP_KERNEL, "bus/usb/%03d/%03d",
+			 usb_dev->bus->busnum, usb_dev->devnum);
+}
+
 struct device_type usb_device_type = {
 	.name =		"usb_device",
 	.release =	usb_release_dev,
 	.uevent =	usb_dev_uevent,
+	.nodename = 	usb_nodename,
 	.pm =		&usb_device_pm_ops,
 };
 
--- a/drivers/usb/misc/iowarrior.c
+++ b/drivers/usb/misc/iowarrior.c
@@ -726,12 +726,18 @@ static const struct file_operations iowa
 	.poll = iowarrior_poll,
 };
 
+static char *iowarrior_nodename(struct device *dev)
+{
+	return kasprintf(GFP_KERNEL, "usb/%s", dev_name(dev));
+}
+
 /*
  * usb class driver info in order to get a minor number from the usb core,
  * and to have the device registered with devfs and the driver core
  */
 static struct usb_class_driver iowarrior_class = {
 	.name = "iowarrior%d",
+	.nodename = iowarrior_nodename,
 	.fops = &iowarrior_fops,
 	.minor_base = IOWARRIOR_MINOR_BASE,
 };
--- a/drivers/usb/misc/legousbtower.c
+++ b/drivers/usb/misc/legousbtower.c
@@ -266,12 +266,18 @@ static const struct file_operations towe
 	.llseek =	tower_llseek,
 };
 
+static char *legousbtower_nodename(struct device *dev)
+{
+	return kasprintf(GFP_KERNEL, "usb/%s", dev_name(dev));
+}
+
 /*
  * usb class driver info in order to get a minor number from the usb core,
  * and to have the device registered with the driver core
  */
 static struct usb_class_driver tower_class = {
 	.name =		"legousbtower%d",
+	.nodename = 	legousbtower_nodename,
 	.fops =		&tower_fops,
 	.minor_base =	LEGO_USB_TOWER_MINOR_BASE,
 };
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -869,6 +869,8 @@ struct usb_driver {
  * struct usb_device_driver - identifies USB device driver to usbcore
  * @name: The driver name should be unique among USB drivers,
  *	and should normally be the same as the module name.
+ * @nodename: Callback to provide a naming hint for a possible
+ *	device node to create.
  * @probe: Called to see if the driver is willing to manage a particular
  *	device.  If it is, probe returns zero and uses dev_set_drvdata()
  *	to associate driver-specific data with the device.  If unwilling
@@ -912,6 +914,7 @@ extern struct bus_type usb_bus_type;
  */
 struct usb_class_driver {
 	char *name;
+	char *(*nodename)(struct device *dev);
 	const struct file_operations *fops;
 	int minor_base;
 };

[patch 04/13] Driver Core: block: add nodename support for block drivers.

[Greg KH]

[-- Attachment #1: driver-core-block-add-nodename-support-for-block-drivers.patch --]
[-- Type: text/plain, Size: 2353 bytes --]

From: Kay Sievers <kay.sievers@vrfy.org>

This adds support for block drivers to report their requested nodename
to userspace.  It also updates a number of block drivers to provide the
needed subdirectory and device name to be used for them.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 block/genhd.c           |   10 ++++++++++
 drivers/block/pktcdvd.c |    7 +++++++
 include/linux/genhd.h   |    2 +-
 3 files changed, 18 insertions(+), 1 deletion(-)

--- a/block/genhd.c
+++ b/block/genhd.c
@@ -985,10 +985,20 @@ struct class block_class = {
 	.name		= "block",
 };
 
+static char *block_nodename(struct device *dev)
+{
+	struct gendisk *disk = dev_to_disk(dev);
+
+	if (disk->nodename)
+		return disk->nodename(disk);
+	return NULL;
+}
+
 static struct device_type disk_type = {
 	.name		= "disk",
 	.groups		= disk_attr_groups,
 	.release	= disk_release,
+	.nodename	= block_nodename,
 };
 
 #ifdef CONFIG_PROC_FS
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -2853,6 +2853,11 @@ static struct block_device_operations pk
 	.media_changed =	pkt_media_changed,
 };
 
+static char *pktcdvd_nodename(struct gendisk *gd)
+{
+	return kasprintf(GFP_KERNEL, "pktcdvd/%s", gd->disk_name);
+}
+
 /*
  * Set up mapping from pktcdvd device to CD-ROM device.
  */
@@ -2905,6 +2910,7 @@ static int pkt_setup_dev(dev_t dev, dev_
 	disk->fops = &pktcdvd_ops;
 	disk->flags = GENHD_FL_REMOVABLE;
 	strcpy(disk->disk_name, pd->name);
+	disk->nodename = pktcdvd_nodename;
 	disk->private_data = pd;
 	disk->queue = blk_alloc_queue(GFP_KERNEL);
 	if (!disk->queue)
@@ -3060,6 +3066,7 @@ static const struct file_operations pkt_
 static struct miscdevice pkt_misc = {
 	.minor 		= MISC_DYNAMIC_MINOR,
 	.name  		= DRIVER_NAME,
+	.name  		= "pktcdvd/control",
 	.fops  		= &pkt_ctl_fops
 };
 
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -140,7 +140,7 @@ struct gendisk {
                                          * disks that can't be partitioned. */
 
 	char disk_name[DISK_NAME_LEN];	/* name of major driver */
-
+	char *(*nodename)(struct gendisk *gd);
 	/* Array of pointers to partitions indexed by partno.
 	 * Protected with matching bdev lock but stat and other
 	 * non-critical accesses use RCU.  Always access through

[patch 05/13] Driver Core: x86: add nodename for cpuid and msr drivers.

[Greg KH]

[-- Attachment #1: driver-core-x86-add-nodename-for-cpuid-and-msr-drivers.patch --]
[-- Type: text/plain, Size: 1566 bytes --]

From: Kay Sievers <kay.sievers@vrfy.org>

This adds support to the x86 cpuid and msr drivers to report the proper
device name to userspace for their devices.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 arch/x86/kernel/cpuid.c |    6 ++++++
 arch/x86/kernel/msr.c   |    6 ++++++
 2 files changed, 12 insertions(+)

--- a/arch/x86/kernel/cpuid.c
+++ b/arch/x86/kernel/cpuid.c
@@ -182,6 +182,11 @@ static struct notifier_block __refdata c
 	.notifier_call = cpuid_class_cpu_callback,
 };
 
+static char *cpuid_nodename(struct device *dev)
+{
+	return kasprintf(GFP_KERNEL, "cpu/%u/cpuid", MINOR(dev->devt));
+}
+
 static int __init cpuid_init(void)
 {
 	int i, err = 0;
@@ -198,6 +203,7 @@ static int __init cpuid_init(void)
 		err = PTR_ERR(cpuid_class);
 		goto out_chrdev;
 	}
+	cpuid_class->nodename = cpuid_nodename;
 	for_each_online_cpu(i) {
 		err = cpuid_device_create(i);
 		if (err != 0)
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -196,6 +196,11 @@ static struct notifier_block __refdata m
 	.notifier_call = msr_class_cpu_callback,
 };
 
+static char *msr_nodename(struct device *dev)
+{
+	return kasprintf(GFP_KERNEL, "cpu/%u/msr", MINOR(dev->devt));
+}
+
 static int __init msr_init(void)
 {
 	int i, err = 0;
@@ -212,6 +217,7 @@ static int __init msr_init(void)
 		err = PTR_ERR(msr_class);
 		goto out_chrdev;
 	}
+	msr_class->nodename = msr_nodename;
 	for_each_online_cpu(i) {
 		err = msr_device_create(i);
 		if (err != 0)

[patch 06/13] Driver Core: dvb: add nodename for dvb drivers

[Greg KH]

[-- Attachment #1: driver-core-dvb-add-nodename-for-dvb-drivers.patch --]
[-- Type: text/plain, Size: 997 bytes --]

From: Kay Sievers <kay.sievers@vrfy.org>

This adds support to the dvb core to report the proper device name to
userspace for their devices.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/media/dvb/dvb-core/dvbdev.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

--- a/drivers/media/dvb/dvb-core/dvbdev.c
+++ b/drivers/media/dvb/dvb-core/dvbdev.c
@@ -447,6 +447,15 @@ static int dvb_uevent(struct device *dev
 	return 0;
 }
 
+static char *dvb_nodename(struct device *dev)
+{
+	struct dvb_device *dvbdev = dev_get_drvdata(dev);
+
+	return kasprintf(GFP_KERNEL, "dvb/adapter%d/%s%d",
+		dvbdev->adapter->num, dnames[dvbdev->type], dvbdev->id);
+}
+
+
 static int __init init_dvbdev(void)
 {
 	int retval;
@@ -469,6 +478,7 @@ static int __init init_dvbdev(void)
 		goto error;
 	}
 	dvb_class->dev_uevent = dvb_uevent;
+	dvb_class->nodename = dvb_nodename;
 	return 0;
 
 error:

[patch 07/13] Driver Core: input: add nodename for input drivers

[Greg KH]

[-- Attachment #1: driver-core-input-add-nodename-for-input-drivers.patch --]
[-- Type: text/plain, Size: 758 bytes --]

From: Kay Sievers <kay.sievers@vrfy.org>

This adds support to the input core to report the proper device name to
userspace for their devices.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/input/input.c |    6 ++++++
 1 file changed, 6 insertions(+)

--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -1264,8 +1264,14 @@ static struct device_type input_dev_type
 	.uevent		= input_dev_uevent,
 };
 
+static char *input_nodename(struct device *dev)
+{
+	return kasprintf(GFP_KERNEL, "input/%s", dev_name(dev));
+}
+
 struct class input_class = {
 	.name		= "input",
+	.nodename	= input_nodename,
 };
 EXPORT_SYMBOL_GPL(input_class);
 

[patch 08/13] Driver Core: sound: add nodename for sound drivers

[Greg KH]

[-- Attachment #1: driver-core-sound-add-nodename-for-sound-drivers.patch --]
[-- Type: text/plain, Size: 851 bytes --]

From: Kay Sievers <kay.sievers@vrfy.org>

This adds support to the sound core to report the proper device name to
userspace for their devices.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 sound/sound_core.c |    7 +++++++
 1 file changed, 7 insertions(+)

--- a/sound/sound_core.c
+++ b/sound/sound_core.c
@@ -27,6 +27,11 @@ MODULE_DESCRIPTION("Core sound module");
 MODULE_AUTHOR("Alan Cox");
 MODULE_LICENSE("GPL");
 
+static char *sound_nodename(struct device *dev)
+{
+	return kasprintf(GFP_KERNEL, "snd/%s", dev_name(dev));
+}
+
 static int __init init_soundcore(void)
 {
 	int rc;
@@ -41,6 +46,8 @@ static int __init init_soundcore(void)
 		return PTR_ERR(sound_class);
 	}
 
+	sound_class->nodename = sound_nodename;
+
 	return 0;
 }
 

[patch 09/13] Driver Core: raw: add nodename for raw devices

[Greg KH]

[-- Attachment #1: driver-core-raw-add-nodename-for-raw-devices.patch --]
[-- Type: text/plain, Size: 926 bytes --]

From: Kay Sievers <kay.sievers@vrfy.org>

This adds support to the raw driver to report the proper device name to
userspace for the raw devices.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/char/raw.c |    6 ++++++
 1 file changed, 6 insertions(+)

--- a/drivers/char/raw.c
+++ b/drivers/char/raw.c
@@ -261,6 +261,11 @@ static const struct file_operations raw_
 
 static struct cdev raw_cdev;
 
+static char *raw_nodename(struct device *dev)
+{
+	return kasprintf(GFP_KERNEL, "raw/%s", dev_name(dev));
+}
+
 static int __init raw_init(void)
 {
 	dev_t dev = MKDEV(RAW_MAJOR, 0);
@@ -284,6 +289,7 @@ static int __init raw_init(void)
 		ret = PTR_ERR(raw_class);
 		goto error_region;
 	}
+	raw_class->nodename = raw_nodename;
 	device_create(raw_class, NULL, MKDEV(RAW_MAJOR, 0), NULL, "rawctl");
 
 	return 0;

[patch 10/13] Driver Core: drm: add nodename for drm devices

[Greg KH]

[-- Attachment #1: driver-core-drm-add-nodename-for-drm-devices.patch --]
[-- Type: text/plain, Size: 901 bytes --]

From: Kay Sievers <kay.sievers@vrfy.org>

This adds support to the drm core to report the proper device name to
userspace for the drm devices.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/gpu/drm/drm_sysfs.c |    7 +++++++
 1 file changed, 7 insertions(+)

--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -70,6 +70,11 @@ static ssize_t version_show(struct class
 		       CORE_MINOR, CORE_PATCHLEVEL, CORE_DATE);
 }
 
+static char *drm_nodename(struct device *dev)
+{
+	return kasprintf(GFP_KERNEL, "dri/%s", dev_name(dev));
+}
+
 static CLASS_ATTR(version, S_IRUGO, version_show, NULL);
 
 /**
@@ -101,6 +106,8 @@ struct class *drm_sysfs_create(struct mo
 	if (err)
 		goto err_out_class;
 
+	class->nodename = drm_nodename;
+
 	return class;
 
 err_out_class:

[patch 11/13] Driver Core: aoe: add nodename for aoe devices

[Greg KH]

[-- Attachment #1: driver-core-aoe-add-nodename-for-aoe-devices.patch --]
[-- Type: text/plain, Size: 966 bytes --]

From: Kay Sievers <kay.sievers@vrfy.org>

This adds support to the AOE core to report the proper device name to
userspace for the AOE devices.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/block/aoe/aoechr.c |    7 +++++++
 1 file changed, 7 insertions(+)

--- a/drivers/block/aoe/aoechr.c
+++ b/drivers/block/aoe/aoechr.c
@@ -266,6 +266,11 @@ static const struct file_operations aoe_
 	.owner = THIS_MODULE,
 };
 
+static char *aoe_nodename(struct device *dev)
+{
+	return kasprintf(GFP_KERNEL, "etherd/%s", dev_name(dev));
+}
+
 int __init
 aoechr_init(void)
 {
@@ -283,6 +288,8 @@ aoechr_init(void)
 		unregister_chrdev(AOE_MAJOR, "aoechr");
 		return PTR_ERR(aoe_class);
 	}
+	aoe_class->nodename = aoe_nodename;
+
 	for (i = 0; i < ARRAY_SIZE(chardevs); ++i)
 		device_create(aoe_class, NULL,
 			      MKDEV(AOE_MAJOR, chardevs[i].minor), NULL,

[patch 12/13] Driver Core: bsg: add nodename for bsg driver

[Greg KH]

[-- Attachment #1: driver-core-bsg-add-nodename-for-bsg-driver.patch --]
[-- Type: text/plain, Size: 880 bytes --]

From: Kay Sievers <kay.sievers@vrfy.org>

This adds support to the BSG driver to report the proper device name to
userspace for the bsg devices.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 block/bsg.c |    6 ++++++
 1 file changed, 6 insertions(+)

--- a/block/bsg.c
+++ b/block/bsg.c
@@ -1062,6 +1062,11 @@ EXPORT_SYMBOL_GPL(bsg_register_queue);
 
 static struct cdev bsg_cdev;
 
+static char *bsg_nodename(struct device *dev)
+{
+	return kasprintf(GFP_KERNEL, "bsg/%s", dev_name(dev));
+}
+
 static int __init bsg_init(void)
 {
 	int ret, i;
@@ -1082,6 +1087,7 @@ static int __init bsg_init(void)
 		ret = PTR_ERR(bsg_class);
 		goto destroy_kmemcache;
 	}
+	bsg_class->nodename = bsg_nodename;
 
 	ret = alloc_chrdev_region(&devid, 0, BSG_MAX_DEVS, "bsg");
 	if (ret)

[patch 13/13] Driver Core: devtmpfs - driver core maintained /dev tmpfs

[Greg KH]

[-- Attachment #1: driver-core-devtmpfs-driver-core-maintained-dev-tmpfs.patch --]
[-- Type: text/plain, Size: 16091 bytes --]


From: Kay Sievers <kay.sievers@vrfy.org>

Devtmpfs lets the kernel create a tmpfs very early at kernel
initialization, before any driver-core device is registered. Every
device with a major/minor will have a device node created in this
tmpfs instance. After the rootfs is mounted by the kernel, the
populated tmpfs is mounted at /dev. In initramfs
"mount --move /dev /root/dev" can move it to the manually mounted
root filesystem before changing into /root and /sbin/init is
executed.

The tmpfs instance can be changed and altered by userspace at any time,
and in any way needed - just like today's udev-mounted tmpfs. Unmodified
udev versions will run just fine on top of it, and will recognize an
already existing kernel-created device node and use it.

The default node permissions are root:root 0600. Proper permissions
and user/group ownership, meaningful symlinks, all other policy besides
the node name, still needs to be applied by udev, just as without
devtmpfs.

If a node is created by devtmps, devtmpfs will remove the device node
when the device goes away. If the device node was created by
userspace, or the devtmpfs created node was replaced by userspace, it
will not be removed by devtmpfs.

This makes init=/bin/sh work without any further userspace support.
/dev will be fully populated and dynamic, and always reflect the current
device state of the kernel. Especially in the face of the already
implemented dynamic device numbers for block devices, this can be very
helpful in a rescue situation, where static devices nodes will no longer
work.
Custom, embedded-like systems should be able to use this as a dynamic
/dev directory without any need for aditional userspace tools.

With the kernel populated /dev, existing initramfs or kernel-mount
bootup logic can be optimized to be more efficient, and not to require a
full coldplug run, which is currently needed to bootstrap the inital
/dev directory content, before continuing bringing up the rest of
the system. There will be no missed events to replay, because /dev is
available before the first kernel device is registered with the
driver-core. A coldplug run can take, depending on the speed of the
system and the amount of devices which need to be handled, from one
to several seconds.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/base/Kconfig     |   17 ++
 drivers/base/Makefile    |    1 
 drivers/base/base.h      |    6 
 drivers/base/core.c      |    3 
 drivers/base/devtmpfs.c  |  354 +++++++++++++++++++++++++++++++++++++++++++++++
 drivers/base/init.c      |    1 
 include/linux/device.h   |   10 +
 include/linux/shmem_fs.h |    2 
 init/do_mounts.c         |    2 
 init/initramfs.c         |    2 
 init/main.c              |    2 
 mm/shmem.c               |    6 
 12 files changed, 401 insertions(+), 5 deletions(-)

--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -134,3 +134,9 @@ static inline void module_add_driver(str
 				     struct device_driver *drv) { }
 static inline void module_remove_driver(struct device_driver *drv) { }
 #endif
+
+#ifdef CONFIG_DEVTMPFS
+extern int devtmpfs_init(void);
+#else
+static inline int devtmpfs_init(void) { return 0; }
+#endif
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -920,6 +920,8 @@ int device_add(struct device *dev)
 		error = device_create_sys_dev_entry(dev);
 		if (error)
 			goto devtattrError;
+
+		devtmpfs_create_node(dev);
 	}
 
 	error = device_add_class_symlinks(dev);
@@ -1063,6 +1065,7 @@ void device_del(struct device *dev)
 	if (parent)
 		klist_del(&dev->p->knode_parent);
 	if (MAJOR(dev->devt)) {
+		devtmpfs_delete_node(dev);
 		device_remove_sys_dev_entry(dev);
 		device_remove_file(dev, &devt_attr);
 	}
--- /dev/null
+++ b/drivers/base/devtmpfs.c
@@ -0,0 +1,354 @@
+/*
+ * /dev tmpfs device nodes
+ *
+ * Copyright (C) 2009, Kay Sievers <kay.sievers@vrfy.org>
+ *
+ * During bootup, before any driver core device is registered, a tmpfs
+ * filesystem is created. Every device which requests a devno, will
+ * create a device node in this filesystem. The node is named after the
+ * the nameof the device, or the susbsytem can provide a custom name
+ * for the node.
+ *
+ * All devices are owned by root. This is intended to simplify bootup, and
+ * make it possible to delay the initial coldplug done by udev in userspace.
+ *
+ * It should also provide a simpler way for rescue systems to bring up a
+ * kernel with dynamic major/minor numbers.
+ */
+
+#include <linux/kernel.h>
+#include <linux/syscalls.h>
+#include <linux/mount.h>
+#include <linux/device.h>
+#include <linux/genhd.h>
+#include <linux/namei.h>
+#include <linux/fs.h>
+
+static struct vfsmount *dev_mnt;
+
+#ifdef CONFIG_BLOCK
+static inline int is_blockdev(struct device *dev)
+{
+	return dev->class == &block_class;
+}
+#else
+static inline int is_blockdev(struct device *dev) { return 0; }
+#endif
+
+static int dev_mkdir(const char *name, mode_t mode)
+{
+	struct nameidata nd;
+	struct dentry *dentry;
+	int err;
+
+	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+			      name, LOOKUP_PARENT, &nd);
+	if (err)
+		return err;
+
+	dentry = lookup_create(&nd, 1);
+	if (!IS_ERR(dentry)) {
+		err = vfs_mkdir(nd.path.dentry->d_inode, dentry, mode);
+		dput(dentry);
+	} else {
+		err = PTR_ERR(dentry);
+	}
+	mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
+
+	path_put(&nd.path);
+	return err;
+}
+
+static int dev_symlink(const char *target, const char *name)
+{
+	struct nameidata nd;
+	struct dentry *dentry;
+	int err;
+
+	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+			      name, LOOKUP_PARENT, &nd);
+	if (err)
+		return err;
+
+	dentry = lookup_create(&nd, 0);
+	if (!IS_ERR(dentry)) {
+		err = vfs_symlink(nd.path.dentry->d_inode, dentry, target);
+		dput(dentry);
+	}
+	mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
+
+	path_put(&nd.path);
+	return err;
+}
+
+static int create_path(const char *nodepath)
+{
+	char *path;
+	struct nameidata nd;
+	int err = 0;
+
+	path = kstrdup(nodepath, GFP_KERNEL);
+	if (!path)
+		return -ENOMEM;
+
+	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+			      path, LOOKUP_PARENT, &nd);
+	if (err == 0) {
+		struct dentry *dentry;
+
+		/* create directory right away */
+		dentry = lookup_create(&nd, 1);
+		if (!IS_ERR(dentry)) {
+			err = vfs_mkdir(nd.path.dentry->d_inode,
+					dentry, 0775);
+			dput(dentry);
+		}
+		mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
+
+		path_put(&nd.path);
+	} else if (err == -ENOENT) {
+		char *s;
+
+		/* parent directories do not exist, create them */
+		s = path;
+		while (1) {
+			s = strchr(s, '/');
+			if (!s)
+				break;
+			s[0] = '\0';
+			err = dev_mkdir(path, 0755);
+			if (err && err != -EEXIST)
+				break;
+			s[0] = '/';
+			s++;
+		}
+	}
+
+	kfree(path);
+	return err;
+}
+
+int devtmpfs_create_node(struct device *dev)
+{
+	const char *tmp = NULL;
+	const char *nodename;
+	mode_t mode;
+	struct nameidata nd;
+	struct dentry *dentry;
+	int err;
+
+	if (!dev_mnt)
+		return 0;
+
+	nodename = device_get_nodename(dev, &tmp);
+	if (!nodename)
+		return -ENOMEM;
+
+	if (is_blockdev(dev))
+		mode = S_IFBLK|0600;
+	else
+		mode = S_IFCHR|0600;
+
+	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+			      nodename, LOOKUP_PARENT, &nd);
+	if (err == -ENOENT) {
+		/* create missing parent directories */
+		create_path(nodename);
+		err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+				      nodename, LOOKUP_PARENT, &nd);
+		if (err)
+			goto out_name;
+	}
+
+	dentry = lookup_create(&nd, 0);
+	if (!IS_ERR(dentry)) {
+		err = vfs_mknod(nd.path.dentry->d_inode,
+				dentry, mode, dev->devt);
+		/* mark as kernel created inode */
+		if (!err)
+			dentry->d_inode->i_private = &dev_mnt;
+		dput(dentry);
+	} else {
+		err = PTR_ERR(dentry);
+	}
+	mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
+
+	path_put(&nd.path);
+out_name:
+	kfree(tmp);
+	return err;
+}
+
+static int dev_rmdir(const char *name)
+{
+	struct nameidata nd;
+	struct dentry *dentry;
+	int err;
+
+	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+			      name, LOOKUP_PARENT, &nd);
+	if (err)
+		return err;
+
+	mutex_lock_nested(&nd.path.dentry->d_inode->i_mutex, I_MUTEX_PARENT);
+	dentry = lookup_one_len(nd.last.name, nd.path.dentry, nd.last.len);
+	if (!IS_ERR(dentry)) {
+		if (dentry->d_inode)
+			err = vfs_rmdir(nd.path.dentry->d_inode, dentry);
+		else
+			err = -ENOENT;
+		dput(dentry);
+	} else {
+		err = PTR_ERR(dentry);
+	}
+	mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
+
+	path_put(&nd.path);
+	return err;
+}
+
+static int delete_path(const char *nodepath)
+{
+	const char *path;
+	int err = 0;
+
+	path = kstrdup(nodepath, GFP_KERNEL);
+	if (!path)
+		return -ENOMEM;
+
+	while (1) {
+		char *base;
+
+		base = strrchr(path, '/');
+		if (!base)
+			break;
+		base[0] = '\0';
+		err = dev_rmdir(path);
+		if (err)
+			break;
+	}
+
+	kfree(path);
+	return err;
+}
+
+static int dev_mynode(struct device *dev, struct inode *inode, struct kstat *stat)
+{
+	/* did we create it */
+	if (inode->i_private != &dev_mnt)
+		return 0;
+
+	/* does the dev_t match */
+	if (is_blockdev(dev)) {
+		if (!S_ISBLK(stat->mode))
+			return 0;
+	} else {
+		if (!S_ISCHR(stat->mode))
+			return 0;
+	}
+	if (stat->rdev != dev->devt)
+		return 0;
+
+	/* ours */
+	return 1;
+}
+
+int devtmpfs_delete_node(struct device *dev)
+{
+	const char *tmp = NULL;
+	const char *nodename;
+	struct nameidata nd;
+	struct dentry *dentry;
+	struct kstat stat;
+	int deleted = 1;
+	int err;
+
+	if (!dev_mnt)
+		return 0;
+
+	nodename = device_get_nodename(dev, &tmp);
+	if (!nodename)
+		return -ENOMEM;
+
+	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+			      nodename, LOOKUP_PARENT, &nd);
+	if (err)
+		goto out_name;
+
+	mutex_lock_nested(&nd.path.dentry->d_inode->i_mutex, I_MUTEX_PARENT);
+	dentry = lookup_one_len(nd.last.name, nd.path.dentry, nd.last.len);
+	if (!IS_ERR(dentry)) {
+		if (dentry->d_inode) {
+			err = vfs_getattr(nd.path.mnt, dentry, &stat);
+			if (!err && dev_mynode(dev, dentry->d_inode, &stat)) {
+				err = vfs_unlink(nd.path.dentry->d_inode,
+						 dentry);
+				if (!err || err == -ENOENT)
+					deleted = 1;
+			}
+		} else {
+			err = -ENOENT;
+		}
+		dput(dentry);
+	} else {
+		err = PTR_ERR(dentry);
+	}
+	mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
+
+	path_put(&nd.path);
+	if (deleted && strchr(nodename, '/'))
+		delete_path(nodename);
+out_name:
+	kfree(tmp);
+	return err;
+}
+
+/* After the root filesystem is mounted by the kernel at /root, or the
+ * initramfs in extracted at /root, this tmpfs will be mounted at /root/dev.
+ */
+int devtmpfs_mount(const char *mountpoint)
+{
+	struct path path;
+	int err;
+
+	if (!dev_mnt)
+		return 0;
+
+	err = kern_path(mountpoint, LOOKUP_FOLLOW, &path);
+	if (err)
+		return err;
+	err = do_add_mount(dev_mnt, &path, 0, NULL);
+	if (err)
+		printk(KERN_INFO "devtmpfs: error mounting %i\n", err);
+	else
+		printk(KERN_INFO "devtmpfs: mounted\n");
+	path_put(&path);
+	return err;
+}
+
+/*
+ * Create tmpfs mount, created core devices will add their device device
+ * nodes here.
+ */
+__init int devtmpfs_init(void)
+{
+	int err;
+
+	dev_mnt = do_kern_mount("tmpfs", 0, "devtmpfs", NULL);
+	if (IS_ERR(dev_mnt)) {
+		err = PTR_ERR(dev_mnt);
+		printk(KERN_ERR "devtmpfs: unable to initialize %i\n", err);
+		dev_mnt = NULL;
+		return -1;
+	}
+
+	/* create common files/directories */
+	dev_mkdir("pts", 0755);
+	dev_mkdir("shm", 01755);
+	dev_symlink("/proc/self/fd", "fd");
+	dev_symlink("/proc/self/fd/0", "stdin");
+	dev_symlink("/proc/self/fd/1", "stdout");
+	dev_symlink("/proc/self/fd/2", "stderr");
+	printk(KERN_INFO "devtmpfs: initialized\n");
+	return 0;
+}
--- a/drivers/base/init.c
+++ b/drivers/base/init.c
@@ -20,6 +20,7 @@
 void __init driver_init(void)
 {
 	/* These are the core pieces */
+	devtmpfs_init();
 	devices_init();
 	buses_init();
 	classes_init();
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -8,6 +8,23 @@ config UEVENT_HELPER_PATH
 	  Path to uevent helper program forked by the kernel for
 	  every uevent.
 
+config DEVTMPFS
+	bool "Create a kernel maintained /dev tmpfs (EXPERIMENTAL)"
+	depends on HOTPLUG
+	help
+	  This creates a tmpfs filesystem, and mounts it at bootup
+	  and mounts it at /dev. The kernel driver core creates device
+	  nodes for all registered devices in that filesystem. All device
+	  nodes are owned by root and have the default mode of 0600.
+	  Userspace can add and delete the nodes as needed. This is
+	  intended to simplify bootup, and make it possible to delay
+	  the initial coldplug at bootup done by udev in userspace.
+	  It should also provide a simpler way for rescue systems
+	  to bring up a kernel with dynamic major/minor numbers.
+	  Meaningful symlinks, permissions and device ownership must
+	  still be handled by userspace.
+	  If unsure, say N here.
+
 config STANDALONE
 	bool "Select only drivers that don't need compile-time external firmware" if EXPERIMENTAL
 	default y
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -4,6 +4,7 @@ obj-y			:= core.o sys.o bus.o dd.o \
 			   driver.o class.o platform.o \
 			   cpu.o firmware.o init.o map.o devres.o \
 			   attribute_container.o transport_class.o
+obj-$(CONFIG_DEVTMPFS)	+= devtmpfs.o
 obj-y			+= power/
 obj-$(CONFIG_HAS_DMA)	+= dma-mapping.o
 obj-$(CONFIG_ISA)	+= isa.o
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -554,6 +554,16 @@ extern void put_device(struct device *de
 
 extern void wait_for_device_probe(void);
 
+#ifdef CONFIG_DEVTMPFS
+extern int devtmpfs_create_node(struct device *dev);
+extern int devtmpfs_delete_node(struct device *dev);
+extern int devtmpfs_mount(const char *mountpoint);
+#else
+static inline int devtmpfs_create_node(struct device *dev) { return 0; }
+static inline int devtmpfs_delete_node(struct device *dev) { return 0; }
+static inline int devtmpfs_mount(const char *mountpoint) { return 0; }
+#endif
+
 /* drivers/base/power/shutdown.c */
 extern void device_shutdown(void);
 
--- a/include/linux/shmem_fs.h
+++ b/include/linux/shmem_fs.h
@@ -42,6 +42,8 @@ static inline struct shmem_inode_info *S
 	return container_of(inode, struct shmem_inode_info, vfs_inode);
 }
 
+extern int init_tmpfs(void);
+
 #ifdef CONFIG_TMPFS_POSIX_ACL
 int shmem_permission(struct inode *, int);
 int shmem_acl_init(struct inode *, struct inode *);
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -414,7 +414,7 @@ void __init prepare_namespace(void)
 
 	mount_root();
 out:
+	devtmpfs_mount("dev");
 	sys_mount(".", "/", NULL, MS_MOVE, NULL);
 	sys_chroot(".");
 }
-
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -8,6 +8,7 @@
 #include <linux/dirent.h>
 #include <linux/syscalls.h>
 #include <linux/utime.h>
+#include <linux/device.h>
 
 static __initdata char *message;
 static void __init error(char *x)
@@ -600,6 +601,7 @@ static int __init populate_rootfs(void)
 			initrd_end - initrd_start);
 		if (err)
 			printk(KERN_EMERG "Initramfs unpacking failed: %s\n", err);
+		devtmpfs_mount("dev");
 		free_initrd();
 #endif
 	}
--- a/init/main.c
+++ b/init/main.c
@@ -64,6 +64,7 @@
 #include <linux/idr.h>
 #include <linux/ftrace.h>
 #include <linux/async.h>
+#include <linux/shmem_fs.h>
 #include <trace/boot.h>
 
 #include <asm/io.h>
@@ -778,6 +779,7 @@ static void __init do_basic_setup(void)
 	init_workqueues();
 	cpuset_init_smp();
 	usermodehelper_init();
+	init_tmpfs();
 	driver_init();
 	init_irq_proc();
 	do_initcalls();
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2523,7 +2523,7 @@ static struct file_system_type tmpfs_fs_
 	.kill_sb	= kill_litter_super,
 };
 
-static int __init init_tmpfs(void)
+int __init init_tmpfs(void)
 {
 	int error;
 
@@ -2580,7 +2580,7 @@ static struct file_system_type tmpfs_fs_
 	.kill_sb	= kill_litter_super,
 };
 
-static int __init init_tmpfs(void)
+int __init init_tmpfs(void)
 {
 	BUG_ON(register_filesystem(&tmpfs_fs_type) != 0);
 
@@ -2691,5 +2691,3 @@ int shmem_zero_setup(struct vm_area_stru
 	vma->vm_ops = &shmem_vm_ops;
 	return 0;
 }
-
-module_init(init_tmpfs)

Re: [patch 00/13] devtmpfs patches

[Fabio Comolli]

Hi.

On Sat, May 9, 2009 at 4:37 PM, Greg KH <greg@kroah.com> wrote:
> Here's the latest version of the devtmpfs patch, broken up into 13
> different patches to make it easier to review and merge properly.
>
> This series does the following:
>  - creates a new callback within the driver core to allow drivers and
>    subsystems to provide a name for their subsystem to properly reflect
>    what userspace should use for their device nodes.  This allows for
>    things like the sound/ and input/ subdirectories to be properly told
>    to userspace.  Note these names and subdirectories are the ones that
>    have been used for years, and are standardized across all
>    distributions and synced up with the LANANA naming scheme which is
>    specified by LSB.  We aren't creating anything new here.
>  - fills in the callbacks by the various subsystems that need to define
>    it, including the misc device layer.  This is the majority of the
>    patches in the series.
>  - adds the devtmpfs core code.  Description of what this is, why it is
>    needed, and how it works is within this patch.
>
> All of these patches have been tested for a number of weeks now in
> SuSE's kernel trees and have proved to increase boot time a measurable
> ammount (a few seconds at the very least)

Well, guess you meant the opposite ;-)


> on both traditional systems
> (servers / desktops) as well as on netbooks using a non-SuSE based
> userspace infrastructure.
>
> This feature also allows rescue systems to work properly by allowing
> systems to boot into /bin/bash with full access to all of their device
> nodes.  It is also a big win on embedded systems with no local users yet
> they need to provide dynamic names as their hardware configuration can
> be changed by external forces.
>
> All of the previous objections to this patch series seems to have been
> properly addressed, but as always, comments are welcome, just make them
> substantial please :)
>
> These patches are now in the driver-core git tree of quilt patches.
>
> thanks,
>
> greg k-h
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [patch 00/13] devtmpfs patches

[Greg KH]

On Sat, May 09, 2009 at 05:10:24PM +0200, Fabio Comolli wrote:
> Hi.
> 
> On Sat, May 9, 2009 at 4:37 PM, Greg KH <greg@kroah.com> wrote:
> > Here's the latest version of the devtmpfs patch, broken up into 13
> > different patches to make it easier to review and merge properly.
> >
> > This series does the following:
> >  - creates a new callback within the driver core to allow drivers and
> >    subsystems to provide a name for their subsystem to properly reflect
> >    what userspace should use for their device nodes.  This allows for
> >    things like the sound/ and input/ subdirectories to be properly told
> >    to userspace.  Note these names and subdirectories are the ones that
> >    have been used for years, and are standardized across all
> >    distributions and synced up with the LANANA naming scheme which is
> >    specified by LSB.  We aren't creating anything new here.
> >  - fills in the callbacks by the various subsystems that need to define
> >    it, including the misc device layer.  This is the majority of the
> >    patches in the series.
> >  - adds the devtmpfs core code.  Description of what this is, why it is
> >    needed, and how it works is within this patch.
> >
> > All of these patches have been tested for a number of weeks now in
> > SuSE's kernel trees and have proved to increase boot time a measurable
> > ammount (a few seconds at the very least)
> 
> Well, guess you meant the opposite ;-)

Heh, yes, sorry about that.  It makes booting faster :)

thanks,

greg k-h

Re: [patch 00/13] devtmpfs patches

[Arjan van de Ven]

On Sat, 9 May 2009 08:08:53 -0700
Greg KH <gregkh@suse.de> wrote:

> > Well, guess you meant the opposite ;-)
> 
> Heh, yes, sorry about that.  It makes booting faster :)

.. and I don't buy that.

The only argument I've heard is "oh but it's hard". No it's not.
The other argument is "but for more partitions we get other device
numbers"... you know what, that's easy to fix. Just make the 32 bit dev
number consistent. Few lines of code I bet, and it is benefit for
everyone to do that....

Beyond that... this is not needed... but at least call it "devfs".. for
what it is.

(and yes there is very obvious irony)


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [patch 00/13] devtmpfs patches

[Greg KH]

On Sat, May 09, 2009 at 08:22:33AM -0700, Arjan van de Ven wrote:
> On Sat, 9 May 2009 08:08:53 -0700
> Greg KH <gregkh@suse.de> wrote:
> 
> > > Well, guess you meant the opposite ;-)
> > 
> > Heh, yes, sorry about that.  It makes booting faster :)
> 
> .. and I don't buy that.

Kay posted numbers showing this.

I have bootchart graphics somewhere around here that also shows this.

> The only argument I've heard is "oh but it's hard". No it's not.

No, it's not "hard", it's just reality :)

> The other argument is "but for more partitions we get other device
> numbers"... you know what, that's easy to fix. Just make the 32 bit dev
> number consistent. Few lines of code I bet, and it is benefit for
> everyone to do that....

Huh?  We need to be able to support large number of partitions at boot
time.  We also need to support an initrd, and not a static /dev/ tree at
boot time, as that is what the world requires from a flexible Linux
distro that runs on multiple types of hardware configurations.

Sure, if you can ensure your hardware platform isn't going to change,
and is relativly limited (as Moblin currently does), then you don't need
an initrd and you can get away with a static /dev and save a few
hundred's of a second.  But the distros can't do that, they are stuck
supporting users with tens of partitions and other "wierd"
configurations.

> Beyond that... this is not needed... but at least call it "devfs".. for
> what it is.

It's not a stand-alone filesystem.  It's an in-kernel mknod on top of
tmpfs.  Heck, if it's just a matter of the name change, I'll gladly do
it.  That doesn't stop the fact that it's still a very useful and needed
option for lots of configurations where Linux is used (embedded, rescue
disks, fast boot on flexable distros, etc.)

> (and yes there is very obvious irony)

devfs was removed for a number of other reasons (bad code, maintainer
left, in-kernel policy that was in contrast to the LSB, modprobe from
within the kernel, thousands of lines of code, etc.)  Turns out that the
idea of a devfs is a good one, and here is a simple, and easy to
understand and maintain implementation of such a thing.

I'll be the first to say this, hence it is without irony that I am
proposing it be included.

If there are any technical problems with the proposed patches, please
let us know.

thanks,

greg k-h

Re: [patch 00/13] devtmpfs patches

[Arjan van de Ven]

On Sat, 9 May 2009 09:19:23 -0700
Greg KH <gregkh@suse.de> wrote:

 
> I have bootchart graphics somewhere around here that also shows this.
> 
> > The only argument I've heard is "oh but it's hard". No it's not.
> 
> No, it's not "hard", it's just reality :)

it's not hard indeed. 

> 
> > The other argument is "but for more partitions we get other device
> > numbers"... you know what, that's easy to fix. Just make the 32 bit
> > dev number consistent. Few lines of code I bet, and it is benefit
> > for everyone to do that....
> 
> Huh?  We need to be able to support large number of partitions at boot
> time. 

yes and ? Of course we do. I fail to see the problem you're trying to
point out.

> We also need to support an initrd, and not a static /dev/ tree

sure. Your /dev tree has 2 parts; a part that IS static if you want to
or not (and this includes /dev/null, /dev/sda2 etc) and there is a
dynamic component. Udev is cheap if you prepopulate the part with
preassigned numbers. Really. We do it. 
udev *is* expensive if you configure it to do the parts that exposes
uuids in /dev as files as well as labels. Don't do that. But your scheme
doesn't change that so it's an invariant. 
(if you insist on having that it'd be not that hard to have udev first
put down the dynamic part of the device nodes that you're complaining
about and in a second, asynchronous step, do the label thing).


> at boot time, as that is what the world requires from a flexible Linux
> distro that runs on multiple types of hardware configurations.

I'm not arguing against that. Just like the same flexible linux distro
detects that it doesn't need an initramfs and skips that to avoid that
penalty.

> 
> Sure, if you can ensure your hardware platform isn't going to change,
> and is relativly limited (as Moblin currently does), then you don't
> need an initrd and you can get away with a static /dev and save a few
> hundred's of a second. 

There's nothing fundamental here in your statement. Moblin currently
does not use an initrd for netbooks because it assumes you're not going
to use a screwdriver to manually add a disk (there's not even space for
a second disk). A minimal initrd for mount-by-label isn't all that hard
or expensive, especially if you do it so that your store where the
partition was with the label, and try there first, and we're obviously
going to do that for non-netbooks.

Moblin obviously does NOT use a static /dev, of course not. A modern
desktop linux just cannot have that.


> But the distros can't do that, they are stuck
> supporting users with tens of partitions and other "wierd"
> configurations.

tens of partitions is NOT a big deal; it is in fact a very false
argument to this discussion. Just make the static devices nodes and be
done with it. Nobody cares if there's a few files in /dev that represent
partitions that you have not made yet. Especially if later on udev
removes them (as it does somewhat by accident in some cases ;-)


Alan wants data, fine, no big deal, I've uploaded a typical moblin
bootchart
(I've tried to cut off the part past X start because that's just not
relevant for this discussion and would confuse things due to the async
nature of getting that started)

it's at
http://www.kernel.org/pub/linux/kernel/people/arjan/bootcharts/bootchart.svg
(done on an Asus EEEpc 901 which obviously doesn't have the fastest cpu
in the world)

while you can see that udev takes about 0.75 seconds there, the
synchronous part of udev (where all the device nodes get made and
drivers modprobed) takes a lot less than that, more like 0.2 or so,
if that.
(before people point out the inefficiencies of using gdm; yes we know
and are working on that)
X is done init at roughly 2.5 seconds into the total boot, (when
gdm-session-worker starts).

If your udev takes longer then I would suggest taking a good look at
your udev setup... 


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [patch 00/13] devtmpfs patches

[Arjan van de Ven]

On Sat, 9 May 2009 09:19:23 -0700
Greg KH <gregkh@suse.de> wrote:


btw... I would be a LOT happier about the solution from a technical
point of view if it wasn't the kernel making the device node, but the
kernel exposing a file with a list of all devices, so that userland can
chose to mknod or not, with which permissions if non-default and with
non-default owners.
So basically (and I'm making up a filename here, don't read too much
into that)

cat /proc/alldevices

c   1     4         foobar
b   8     0         sda
c   122   12        dri/card0

etc
making the actual nodes from this in the most simple case is basically
no time in userspace, but a slightly more advanced early userspace app
can even do permissions for the few device nodes where it matters etc.

I can imagine that being a good solution that ends up solving your
problem, but in a way that is more consistent with what the kernel does
right now and how we can then have userland make decisions on where to
make the nodes, with what perms etc etc.
In fact such a file would be a greeat help in general, and would be a
nice generic solution.



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [patch 00/13] devtmpfs patches

[Eric W. Biederman]

Arjan van de Ven <arjan@infradead.org> writes:

> On Sat, 9 May 2009 09:19:23 -0700
> Greg KH <gregkh@suse.de> wrote:
>
>
> btw... I would be a LOT happier about the solution from a technical
> point of view if it wasn't the kernel making the device node, but the
> kernel exposing a file with a list of all devices, so that userland can
> chose to mknod or not, with which permissions if non-default and with
> non-default owners.
> So basically (and I'm making up a filename here, don't read too much
> into that)
>
> cat /proc/alldevices
>
> c   1     4         foobar
> b   8     0         sda
> c   122   12        dri/card0
>
> etc
> making the actual nodes from this in the most simple case is basically
> no time in userspace, but a slightly more advanced early userspace app
> can even do permissions for the few device nodes where it matters etc.
>
> I can imagine that being a good solution that ends up solving your
> problem, but in a way that is more consistent with what the kernel does
> right now and how we can then have userland make decisions on where to
> make the nodes, with what perms etc etc.
> In fact such a file would be a greeat help in general, and would be a
> nice generic solution.

I just did a tiny 100 line test app.

It took me all of 0.06s to mount /sys and /dev and to walk sysfs and
create all 649 of the device nodes. 

I had recently done "echo 3 > /proc/sys/vm/drop_caches" to ensure
that the test was cache cold.

Looking at Kay's test data he doesn't even try and mount root until
0.2s in.

It seems to me that 0.06s is in the noise, small enough that if even
0.06s is limiting basic optimization work is called for.

Eric

Re: [patch 00/13] devtmpfs patches

[Eric W. Biederman]

ebiederm@xmission.com (Eric W. Biederman) writes:

> Arjan van de Ven <arjan@infradead.org> writes:
>
>> On Sat, 9 May 2009 09:19:23 -0700
>> Greg KH <gregkh@suse.de> wrote:
>>
>>
>> btw... I would be a LOT happier about the solution from a technical
>> point of view if it wasn't the kernel making the device node, but the
>> kernel exposing a file with a list of all devices, so that userland can
>> chose to mknod or not, with which permissions if non-default and with
>> non-default owners.
>> So basically (and I'm making up a filename here, don't read too much
>> into that)
>>
>> cat /proc/alldevices
>>
>> c   1     4         foobar
>> b   8     0         sda
>> c   122   12        dri/card0
>>
>> etc
>> making the actual nodes from this in the most simple case is basically
>> no time in userspace, but a slightly more advanced early userspace app
>> can even do permissions for the few device nodes where it matters etc.
>>
>> I can imagine that being a good solution that ends up solving your
>> problem, but in a way that is more consistent with what the kernel does
>> right now and how we can then have userland make decisions on where to
>> make the nodes, with what perms etc etc.
>> In fact such a file would be a greeat help in general, and would be a
>> nice generic solution.
>
> I just did a tiny 100 line test app.
>
> It took me all of 0.06s to mount /sys and /dev and to walk sysfs and
> create all 649 of the device nodes. 

Ok.  I just asked the question how much is mknod and how much is
traversing /sys.

If the I hard code the devices to make in my test app the time is,
0.01s, even on my old 700Mhz amd k7.  So the time to traverse sys to
find the device numbers is a big part of the cost.

At the same time.  Things can potentially be sped up quite a bit by
walking /sys/dev/block and /sys/dev/char and just calling readlink.

A cheaper way of reading the devices out of sysfs might be in order,
to ensure the bottleneck is mknod speed.  But I just don't see this
gating boot speed.

Eric

Re: [patch 00/13] devtmpfs patches

[Andrew Morton]

On Sat, 9 May 2009 09:19:23 -0700 Greg KH <gregkh@suse.de> wrote:

>  We need to be able to support large number of partitions at boot
> time. 

I suspect that the intersection between (systems which need to shave
boot time to the minimum) and (systems which have lots of partitions)
is quite small?

Re: [patch 00/13] devtmpfs patches

[Greg KH]

On Sat, May 09, 2009 at 10:34:54PM -0700, Andrew Morton wrote:
> On Sat, 9 May 2009 09:19:23 -0700 Greg KH <gregkh@suse.de> wrote:
> 
> >  We need to be able to support large number of partitions at boot
> > time. 
> 
> I suspect that the intersection between (systems which need to shave
> boot time to the minimum) and (systems which have lots of partitions)
> is quite small?

No, not at all, lots of desktops have one or two disks with 15+
partitions.  Those users want fast boot times as well.

thanks,

greg k-h

Re: [patch 00/13] devtmpfs patches

[Arjan van de Ven]

On Sun, 10 May 2009 08:20:05 -0700
Greg KH <gregkh@suse.de> wrote:

> On Sat, May 09, 2009 at 10:34:54PM -0700, Andrew Morton wrote:
> > On Sat, 9 May 2009 09:19:23 -0700 Greg KH <gregkh@suse.de> wrote:
> > 
> > >  We need to be able to support large number of partitions at boot
> > > time. 
> > 
> > I suspect that the intersection between (systems which need to shave
> > boot time to the minimum) and (systems which have lots of
> > partitions) is quite small?
> 
> No, not at all, lots of desktops have one or two disks with 15+
> partitions.  Those users want fast boot times as well.

if partitions > 15 don't have stable numbers surely we could fix
that....


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [patch 00/13] devtmpfs patches

[Peter Zijlstra]

On Sun, 2009-05-10 at 08:20 -0700, Greg KH wrote:
> On Sat, May 09, 2009 at 10:34:54PM -0700, Andrew Morton wrote:
> > On Sat, 9 May 2009 09:19:23 -0700 Greg KH <gregkh@suse.de> wrote:
> > 
> > >  We need to be able to support large number of partitions at boot
> > > time. 
> > 
> > I suspect that the intersection between (systems which need to shave
> > boot time to the minimum) and (systems which have lots of partitions)
> > is quite small?
> 
> No, not at all, lots of desktops have one or two disks with 15+
> partitions.  Those users want fast boot times as well.

/me boggles, however does one end up with that many partitions on so few
disks? 

/boot
/
/home
/usr
swap
/usr/local
/opt

and I'm seriously out of sensible ideas.

Re: [patch 00/13] devtmpfs patches

[Alan Cox]

> /me boggles, however does one end up with that many partitions on so few
> disks? 

It happens. Tejun did the extending because libata users were really
hitting these limits.
 
> /boot
> /
> /home
> /usr
> swap
> /usr/local
> /opt
> 
> and I'm seriously out of sensible ideas.

I've seen two usual variants

	Fedora & Unbuntu & Debian & ....

	Fedora 10 & Rawhide & Fedora 9 & ...

for people who like to play with distros or need to test a product on them


and once you do that 16 is quite easy

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Sun, May 10, 2009 at 23:19, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> /me boggles, however does one end up with that many partitions on so few
>> disks?
>
> It happens. Tejun did the extending because libata users were really
> hitting these limits.
>
>> /boot
>> /
>> /home
>> /usr
>> swap
>> /usr/local
>> /opt
>>
>> and I'm seriously out of sensible ideas.
>
> I've seen two usual variants
>
>        Fedora & Unbuntu & Debian & ....
>
>        Fedora 10 & Rawhide & Fedora 9 & ...
>
> for people who like to play with distros or need to test a product on them
>
> and once you do that 16 is quite easy

That's right. Also people with virtualization, running many guest from
individual partitions, like to do that - and 16 is nothing for them.
:)

Some of us run the dynamic sd minors already, and it's not unlikely we
will enable it pretty soon for the distro.

Thanks,
Kay

Re: [patch 00/13] devtmpfs patches

[Arjan van de Ven]

On Mon, 11 May 2009 01:47:16 +0200
Kay Sievers <kay.sievers@vrfy.org> wrote:

> On Sun, May 10, 2009 at 23:19, Alan Cox <alan@lxorguk.ukuu.org.uk>
> wrote:
> >> /me boggles, however does one end up with that many partitions on
> >> so few disks?
> >
> > It happens. Tejun did the extending because libata users were really
> > hitting these limits.
> >
> >> /boot
> >> /
> >> /home
> >> /usr
> >> swap
> >> /usr/local
> >> /opt
> >>
> >> and I'm seriously out of sensible ideas.
> >
> > I've seen two usual variants
> >
> >        Fedora & Unbuntu & Debian & ....
> >
> >        Fedora 10 & Rawhide & Fedora 9 & ...
> >
> > for people who like to play with distros or need to test a product
> > on them
> >
> > and once you do that 16 is quite easy
> 
> That's right. Also people with virtualization, running many guest from
> individual partitions, like to do that - and 16 is nothing for them.
> :)
> 
> Some of us run the dynamic sd minors already, and it's not unlikely we
> will enable it pretty soon for the distro.
> 

I'm still missing why > 16 implies "dynamic"/..

(and it seems to be irrelevant to the devtmpfs discussion anyway since
Eric Biederman has shown that pulling the device numbers out of sysfs
is basically free... even though it'd be nice to give that some help to 
make it a nice index)



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [patch 00/13] devtmpfs patches

[Eric W. Biederman]

Kay Sievers <kay.sievers@vrfy.org> writes:

> On Mon, May 11, 2009 at 02:00, Arjan van de Ven <arjan@infradead.org> wrote:
>> (and it seems to be irrelevant to the devtmpfs discussion anyway since
>> Eric Biederman has shown that pulling the device numbers out of sysfs
>> is basically free... even though it'd be nice to give that some help to
>> make it a nice index)

> Devtmpfs is the simplest, is the fastest, is the most reliable, and it
> is the most flexible 

FLEXIBLE?

> option for us. And still, nobody will be forced
> to use it, it's entirely optional. For our systems, we decided to do
> it that way, and we ship it already in the distro, and if there are no
> substantial problems coming up, which we don't expect, we will
> continue using it.

Yes but you are asking all of us to maintain it.  Forever in perpetuity.
A better case needs to be made than you have already shipped the code.

I'm sorry you decided to ship the code before getting a review.  I
guess that is the definition of an experimental feature.  One not in
the upstream kernel.

> You might not like it for whatever reason.

I think your justification for this ``feature'' is strongly flawed.

You claim to save 2 seconds of a process that should take less than
a tenth of a second.

You claim flexibility while removing user space from the policy loop.

You claim speed increases when comparing to a dog slow non-tuned
implementation.

> And we consider this problem as solved.

What backroom have you had that discussion?

You are presenting this as a decision already made.  I think you
are not playing well with others.

I don't see a case having been made that the existing user
space interface is broken.  Just that the udev implementation
is slow.

I think a slow user space application is simply not a justification
for putting code in the kernel.

I think a developer using faulty arguments for their code likely
has not thought things through and that is enough reason to call
suspicion onto the code in my opinion.

Eric

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Mon, May 11, 2009 at 04:36, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> Devtmpfs is the simplest, is the fastest, is the most reliable, and it
>> is the most flexible
>
> FLEXIBLE?

Yes, flexible because you can do whatever you want in whatever order
and never run into problems with an empty /dev. You can even just
ignore /dev and go ahead. There are basically no dependencyies to do
other things in parallel.

>> option for us. And still, nobody will be forced
>> to use it, it's entirely optional. For our systems, we decided to do
>> it that way, and we ship it already in the distro, and if there are no
>> substantial problems coming up, which we don't expect, we will
>> continue using it.
>
> Yes but you are asking all of us to maintain it.  Forever in perpetuity.
> A better case needs to be made than you have already shipped the code.

I would be very careful with such statement if you want us to accept
your namespace hacks in the future. I guess if we ask with your next
round "do we want to to have to maintain this for forever" you get a
very different answer than today.

> I'm sorry you decided to ship the code before getting a review.  I
> guess that is the definition of an experimental feature.  One not in
> the upstream kernel.

No, I did decide to ship it in the distro which is how things work
since forever. And it's not in the upstream kernel now, while this
discussion happens.

>> You might not like it for whatever reason.
>
> I think your justification for this ``feature'' is strongly flawed.

I did not hear any substantial technical argument so far.

> You claim to save 2 seconds of a process that should take less than
> a tenth of a second.
>
> You claim flexibility while removing user space from the policy loop.

The made up numbers you are bringing up here, suggest that you never
worked in that area, and really, can you please talk about things you
have experience with, or get the needed one _before_ calling things
"flawed", "slow". You even suggest non-working racy hacks instead,
which is far from funny.

> You claim speed increases when comparing to a dog slow non-tuned
> implementation.

Again. nothing is dog-slow. We just don't do unreliable bad hacks like
you suggest. Have you ever wondered why _every_ distro does it this
way? Maybe they are all stupid and just wait for you to tell them and
solve their problem.

>> And we consider this problem as solved.
>
> What backroom have you had that discussion?

I wrote like ten times as many words as are in the patch, here in this
thread. I don't think there is any backroom here.

> You are presenting this as a decision already made.  I think you
> are not playing well with others.

Oh, like calling stuff "flawed", "dog-slow", while not even seen any
of this running for real?

> I don't see a case having been made that the existing user
> space interface is broken.  Just that the udev implementation
> is slow.

That's utter nonsense. It's not slow at all, it's just slower that
what we can do with the bit of help from the kernel.

> I think a slow user space application is simply not a justification
> for putting code in the kernel.

Can you read? Did you read the many reasons why we want this? I guess not.

> I think a developer using faulty arguments for their code likely
> has not thought things through and that is enough reason to call
> suspicion onto the code in my opinion.

You seem running in circles with searching for a "suspicion". Care to
provide a technical argument for the first time? That would be
appreciated.

Thanks,
Kay

Re: [patch 00/13] devtmpfs patches

[Alan Cox]

> I would be very careful with such statement if you want us to accept
> your namespace hacks in the future. I guess if we ask with your next
> round "do we want to to have to maintain this for forever" you get a
> very different answer than today.

Take your unpleasant threatening attitude somewhere else. There are a lot
of people very interested in namespaces.

> > I'm sorry you decided to ship the code before getting a review.  I
> > guess that is the definition of an experimental feature.  One not in
> > the upstream kernel.
> 
> No, I did decide to ship it in the distro which is how things work
> since forever. And it's not in the upstream kernel now, while this
> discussion happens.

And since forever the upstream approach has been "we don't care if you
shipped it first, that's *your* problem"

You've yet to demonstrate
- That your patches are a real speed up
- That dumping more crap in kernel without policy and management is a
  good idea
- That the other proposals are worse than yours.

Arjan produced detailed boot graphs and boots a box very fast indeed. I
see no boot graphs, no detailed analysis here. 

Instead we have obnoxious threats to Eric Biederman and an "I am going to
ram this into the kernel whatever" approach.

Neither are constructive or useful and this isn't the way the Linux
kernel project works. Yes maybe you can stuff things into Greg's tree
easily because you both work for SuSE but that isn't the right way to do
stuff for upstream.

Alan

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Mon, May 11, 2009 at 12:55, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> You've yet to demonstrate
> - That your patches are a real speed up

And I did, and it's obvious that creating a single file along with the
~10 we already create in /sys, instead of running through /sys or
/proc later and reconstruct what we missed, is always, and in every
case faster and simpler. It gets rid of a bunch of things we need to
do today, and depending how much of the things you remove, you get
faster. It's a different model and hard to compare directly. But for a
fact, you can never be faster than the kernel provided nodes.

> - That dumping more crap in kernel without policy and management is a
>  good idea

What exactly do you find is "crap"? What do you mean with "management"?

> - That the other proposals are worse than yours.

I also did, in exactly this thread.

> Arjan produced detailed boot graphs and boots a box very fast indeed. I
> see no boot graphs, no detailed analysis here.

I did in a reply to your earlier mail. And also mentioned the
init=/bin/sh case, which I think, would be reason enough alone,
without all the other gains, to do that.

> Instead we have obnoxious threats to Eric Biederman and an "I am going to
> ram this into the kernel whatever" approach.

Nobody says such thing. I just defend against "dog-slow", "backroom",
and the proposal of even more broken hacks to solve this very problem.
There is no hammering at all, it's just my personal discomfort with
replies who ignore the real issues, and bring up false facts.

> Neither are constructive or useful and this isn't the way the Linux
> kernel project works.

You might be right here, I don't disagree. It's becoming more a
personal issue than a technical, and sorry for that. But stuff like
this happens sometimes, and it's also sometimes "how the kernel
project works". :) Again, sorry.

> Yes maybe you can stuff things into Greg's tree
> easily because you both work for SuSE but that isn't the right way to do
> stuff for upstream.

Come on. You can not convince Greg about anything, just because you
happen to work for the same company. Many of us share a company with
others, also you did in the past and you do now - and we will get
nowhere bringing up such conspiracy statements.

We came up with this, because we think it is the right thing, and it
has proven to solve our problems, and I'm personally still convinced
it is the best option, that's all.

Thanks,
Kay

Re: [patch 00/13] devtmpfs

[Arjan van de Ven]

On Mon, 11 May 2009 13:34:52 +0200
Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > - That the other proposals are worse than yours.
> 
> I also did, in exactly this thread.

no you have not. But I'd like you to ;)

You have not commented substantially on my counter proposal to make the
single file with the "device list" (eg char/block, major, minor, name)
so that userland can make the nodes in 0.01-or-less seconds, but
with the permissions/owners it wants and the tmpfs mount options it
wants.

Again this makes for a more flexible solution (not flexible in "if you
don't like it don't use it" sense but flexible in the "there's multiple
uses and ways to use it" sense) while keeping the benefits of what you
want to achieve. 

Eric has shown that making the nodes itself and mounting the tmpfs is
basically free, but that the cost (0.05 seconds) was in groveling
through sysfs. Fixing that.. I'm all for it. 

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [patch 00/13] devtmpfs

[Kay Sievers]

On Mon, May 11, 2009 at 15:05, Arjan van de Ven <arjan@infradead.org> wrote:
> On Mon, 11 May 2009 13:34:52 +0200
> Kay Sievers <kay.sievers@vrfy.org> wrote:
>>
>> > - That the other proposals are worse than yours.
>>
>> I also did, in exactly this thread.
>
> no you have not. But I'd like you to ;)

I did. It's reliability, the race for new devices coming in when you
start reading your list and finishing creating the nodes. You will
miss these device, which we don't want to work around with another
hack. You will have to bring up the machinery that listens to events
for new devices, before synthesizing the stuff that is already there.

> You have not commented substantially on my counter proposal to make the
> single file with the "device list" (eg char/block, major, minor, name)
> so that userland can make the nodes in 0.01-or-less seconds, but
> with the permissions/owners it wants and the tmpfs mount options it
> wants.

I did. We have all that information in /sys already. I don't see the
reason for another file other than to provide the information to make
just another new userspace hack a bit more efficient.

> Again this makes for a more flexible solution (not flexible in "if you
> don't like it don't use it" sense but flexible in the "there's multiple
> uses and ways to use it" sense) while keeping the benefits of what you
> want to achieve.

Sure, but it's already in /sys today, and we use it that way already.

> Eric has shown that making the nodes itself and mounting the tmpfs is
> basically free, but that the cost (0.05 seconds) was in groveling
> through sysfs. Fixing that.. I'm all for it.

The point is the mentioned race, which we need to cover.

And the main point is the reliability, let all the weird speed
arguments and made-up numbers alone. You depend on whatever rather
complex userspace to bring your box. And people complain about that
for years, and for good reason.

On my box we create 12152 files in /sys on bootup, and with devtmps
the same code creates 218 simple device nodes with the same call, and
this makes bootup reliable, more self-contained, and as a nice side
effect makes it faster. Just focus on init=/bin/sh, if you want to see
the reason behind all this.

We focused on the speed here, because we want to solve the initramfs
problem, a problem you solved by getting rid of it entirely, which is
what I do on all my own boxes too, but what the distro guys will never
want to accept.

Thanks,
Kay

Re: [patch 00/13] devtmpfs

[Arjan van de Ven]

On Mon, 11 May 2009 15:28:33 +0200
Kay Sievers <kay.sievers@vrfy.org> wrote:

> On Mon, May 11, 2009 at 15:05, Arjan van de Ven <arjan@infradead.org>
> wrote:
> > On Mon, 11 May 2009 13:34:52 +0200
> > Kay Sievers <kay.sievers@vrfy.org> wrote:
> >>
> >> > - That the other proposals are worse than yours.
> >>
> >> I also did, in exactly this thread.
> >
> > no you have not. But I'd like you to ;)
> 
> I did. It's reliability, the race for new devices coming in when you
> start reading your list and finishing creating the nodes. You will
> miss these device, which we don't want to work around with another
> hack. You will have to bring up the machinery that listens to events
> for new devices, before synthesizing the stuff that is already there.

and this is hard because ?
certainly udev already does the listen machinery as its first step;
after setting that up, quickly racing down a "list" (whatever form you
make that in) and then daemonizing to work through the events shouldn't
be a problem. 

(and you are right, while this is not an issue without initramfs,
because the kernel doesn't return until all probing activity has
finished, it might be a problem for initramfs, because that executes
before all the probing is done. But it's not a hard issue, just a
sequencing issue)

> 
> > You have not commented substantially on my counter proposal to make
> > the single file with the "device list" (eg char/block, major,
> > minor, name) so that userland can make the nodes in 0.01-or-less
> > seconds, but with the permissions/owners it wants and the tmpfs
> > mount options it wants.
> 
> I did. We have all that information in /sys already. I don't see the
> reason for another file other than to provide the information to make
> just another new userspace hack a bit more efficient.

I personally don't think the 0.06 seconds are a problem, but I got the
impression that you were trying to optimize this path with your patch.
(After all, it is pretty much the cost of the thing you're optimizing)

> 
> And the main point is the reliability, let all the weird speed
> arguments and made-up numbers alone. 

I'm sorry, but you're either trying to be obnoxious or telling us your
own numbers are made up. Since I doubt the former, and neither my nor
Erics numbers are made up, I'll assume the later...

> You depend on whatever rather
> complex userspace to bring your box. And people complain about that
> for years, and for good reason.

prior to sysfs people depended on MAKEDEV (and the fact that they chose
to not use tmpfs but a real fs for /dev) for this. It's not that much
different today. Using tmpfs for /dev is a local choice. It's fully
optional in fact.. and that's a good thing.
> 
> On my box we create 12152 files in /sys on bootup, and with devtmps
> the same code creates 218 simple device nodes with the same call, and
> this makes bootup reliable, more self-contained, and as a nice side
> effect makes it faster. Just focus on init=/bin/sh, if you want to see
> the reason behind all this.

init=/bin/sh is an interesting subcase, sure. It means in the "before
your patch" scenario that people get the "real /dev directory", and not
the tmpfs overmount. It's a distro choice what to put there. Fedora puts
nothing there, Moblin puts only all static-allocated device nodes there.
I don't know what openSuSE puts there. 

People who use init=/bin/sh don't expect a full system, yet they expect
a certain amount of system that allows them to do system recovery I
suppose. I don't consider the delta between "static nodes only" and
"devshmfs" to be significant here. In a recovery scenario, if you WANT
something dynamic you start the thing to do dynamic by hand. Otherwise
you want something predictable.


> We focused on the speed here, because we want to solve the initramfs
> problem, a problem you solved by getting rid of it entirely, which is
> what I do on all my own boxes too, but what the distro guys 
> never want to accept.

Now you've lost me. I am missing the link between this and initramfs
entirely. How you do /dev has extremely little to do with initramfs or
not. Sure you need the rootfs device node before you can mount root for
the initramfs case, just like you need the rootfs device node before
you can fsck it in the non-initramfs case. In both cases you want all
the device nodes as fast as you can, but within the system policy of
ownership, permissions, selinux contexts, tmpfs mount options etc.
And Eric showed that that is a 0.06 second thing.. not a big deal in
the grand scheme of things, even if you want to boot the whole system
in 2 seconds like we do.

Also you're rather generalizing with "the distro guys"... the Moblin
distribution already does this for the cases where it is possible. I
wouldn't be surprised if other distros figured out how to detect this
case and ditch the initramfs when it's possible, while keeping it and
doing it cheaply when it's required to have an initramfs.

-- 
Arjan van de Ven 	Intel Open Source Technology Centre

Re: [patch 00/13] devtmpfs

[Kay Sievers]

On Mon, May 11, 2009 at 15:49, Arjan van de Ven <arjan@infradead.org> wrote:
>> On Mon, May 11, 2009 at 15:05, Arjan van de Ven <arjan@infradead.org>
>> wrote:
>> > On Mon, 11 May 2009 13:34:52 +0200
>> > Kay Sievers <kay.sievers@vrfy.org> wrote:
>> >>
>> >> > - That the other proposals are worse than yours.
>> >>
>> >> I also did, in exactly this thread.
>> >
>> > no you have not. But I'd like you to ;)
>>
>> I did. It's reliability, the race for new devices coming in when you
>> start reading your list and finishing creating the nodes. You will
>> miss these device, which we don't want to work around with another
>> hack. You will have to bring up the machinery that listens to events
>> for new devices, before synthesizing the stuff that is already there.
>
> and this is hard because ?

No, I just object to the "it's free" statement. :)

> (and you are right, while this is not an issue without initramfs,
> because the kernel doesn't return until all probing activity has
> finished, it might be a problem for initramfs, because that executes
> before all the probing is done. But it's not a hard issue, just a
> sequencing issue)

Right, and we would like to get the freedom of doing anything in
parallel to that step. If it's done race-free, it's not really cheap
anymore.

> I personally don't think the 0.06 seconds are a problem, but I got the
> impression that you were trying to optimize this path with your patch.
> (After all, it is pretty much the cost of the thing you're optimizing)

Nah, I wanted to de-couple userspace dependencies to get a working
/dev, so userspace can go ahead and do as many tasks as possible, as
early as possible, without the restrictions to wait for another
process to synthesize a working /dev first. We are optimizing for
robustness and simplicity, and not for speed, that's just the
side-effect, and what motivated us.

>> And the main point is the reliability, let all the weird speed
>> arguments and made-up numbers alone.
>
> I'm sorry, but you're either trying to be obnoxious or telling us your
> own numbers are made up. Since I doubt the former, and neither my nor
> Erics numbers are made up, I'll assume the later...

Sorry, if that was reading wrong. I meant replies like:

"I think your justification for this ``feature'' is strongly flawed.
You claim to save 2 seconds of a process that should take less than a
tenth of a second. You claim flexibility while removing user space
from the policy loop. You claim speed increases when comparing to a
dog slow non-tuned implementation."

I don't even know from what we could save 2 full seconds today.

>> You depend on whatever rather
>> complex userspace to bring your box. And people complain about that
>> for years, and for good reason.
>
> prior to sysfs people depended on MAKEDEV (and the fact that they chose
> to not use tmpfs but a real fs for /dev) for this. It's not that much
> different today. Using tmpfs for /dev is a local choice. It's fully
> optional in fact.. and that's a good thing.

Sure, that's good.

>> On my box we create 12152 files in /sys on bootup, and with devtmps
>> the same code creates 218 simple device nodes with the same call, and
>> this makes bootup reliable, more self-contained, and as a nice side
>> effect makes it faster. Just focus on init=/bin/sh, if you want to see
>> the reason behind all this.
>
> init=/bin/sh is an interesting subcase, sure. It means in the "before
> your patch" scenario that people get the "real /dev directory", and not
> the tmpfs overmount. It's a distro choice what to put there. Fedora puts
> nothing there, Moblin puts only all static-allocated device nodes there.
> I don't know what openSuSE puts there.

Usually it contained a few nodes, but I've seen an empty /dev too.

> People who use init=/bin/sh don't expect a full system, yet they expect
> a certain amount of system that allows them to do system recovery I
> suppose. I don't consider the delta between "static nodes only" and
> "devshmfs" to be significant here. In a recovery scenario, if you WANT
> something dynamic you start the thing to do dynamic by hand. Otherwise
> you want something predictable.

I think it fits nicely to sysfs, and solves the init=/bin/sh problem
quit nicely, and is more "predictable" than the usual /dev content, in
the light of the current state of dynamic numbers.

It's not worth too much to have something predictably non-working. :)

>> We focused on the speed here, because we want to solve the initramfs
>> problem, a problem you solved by getting rid of it entirely, which is
>> what I do on all my own boxes too, but what the distro guys
>> never want to accept.
>
> Now you've lost me. I am missing the link between this and initramfs
> entirely. How you do /dev has extremely little to do with initramfs or
> not. Sure you need the rootfs device node before you can mount root for
> the initramfs case, just like you need the rootfs device node before
> you can fsck it in the non-initramfs case.

Yeah, and random tools you want to start as early as possible, you
need to delay until /dev is working.

> In both cases you want all
> the device nodes as fast as you can,

Which can never be faster than using devtmpfs. :)

> but within the system policy of
> ownership, permissions, selinux contexts, tmpfs mount options etc.

That's what udev still does, and will continue to do so. It's just
de-coupled from bringing up the mandatory basics of the system. All
the policy still lives in udev as it does today, it can just be
applied in the background unlike today.

> And Eric showed that that is a 0.06 second thing.. not a big deal in
> the grand scheme of things, even if you want to boot the whole system
> in 2 seconds like we do.

Yeah, and I object to just another userspace hack which makes things
even more complex as they already are. And it will always be slower
and less robust than the devtmpfs thing too.

> Also you're rather generalizing with "the distro guys"... the Moblin
> distribution already does this for the cases where it is possible. I
> wouldn't be surprised if other distros figured out how to detect this
> case and ditch the initramfs when it's possible, while keeping it and
> doing it cheaply when it's required to have an initramfs.

Yeah, that might be nice to have, but there are not many boxes that
can not get a disk added, and you need a reliable way to cope with
that, and today that is initramfs. It's great that Moblin can do that,
but I meant general purpose distros, which can not know much of the
environment in advance they will run on.

Thanks,
Kay

Re: [patch 00/13] devtmpfs patches

[Alan Cox]

> And I did, and it's obvious that creating a single file along with the
> ~10 we already create in /sys, instead of running through /sys or
> /proc later and reconstruct what we missed, is always, and in every
> case faster and simpler. It gets rid of a bunch of things we need to

Arjan's numbers for sysfs are 0.06 seconds if I remember the mail
correctly. That doesn't account for any meaningful speedup.

> > - That dumping more crap in kernel without policy and management is a
> >  good idea
> 
> What exactly do you find is "crap"? What do you mean with "management"?

Device spaces have user controlled naming rules, user controlled
permissions, user controlled labelling and the like. That is policy, and
the administering of that is management.

That was one of the things that killed devfs eventually, and it's not a
problem your proposal or devfs solved.

> 
> > - That the other proposals are worse than yours.
> 
> I also did, in exactly this thread.

Sorry, but I can't find any convincing evidence in the mails. I see
unhelpful things like you calling Arjan's numbers "made up", despite the
fact he has spent months working on speeding up boot and has probably the
most detailed analysis and data sets anyone does.

In fact I see a litany of comments in response to technical queries and
asking you to justify the code (as opposed to you trying to ask anyone to
justify why it shouldn't get dumped in tree)

Most of those comments are not helpful

> > Arjan produced detailed boot graphs and boots a box very fast indeed. I
> > see no boot graphs, no detailed analysis here.
> 
> I did in a reply to your earlier mail. And also mentioned the
> init=/bin/sh case, which I think, would be reason enough alone,
> without all the other gains, to do that.

I think you actually hit the nail on the head a lot earlier when you
asked Arjan  "How will you solve the dynamic device numbers". Which is
that we could fix them ....

What is the real underlying concern and what problem should we fix.

We have at least six takes on this

1.	What problem ?
2.	The udev userspace setup you are using sucks so fix it
3.	Udev sucks because it can't get the early boot events so has to
do it the hard way - so queue them
4.	Udev sucks because it can't get the early boot events so create
a single table for it to read
5.	Make the new big block numbers stable
6.	Recreate devfs in a new but more clean form

I don't buy take #1 so I would like to understand

- Why Arjan's systems boot very fast and yours don't

- Why you think sysfs changes will help when the stats say its 0.06 of a
  second and udev is not it appears taking much time anyway

- How you think you've solved the devfs problems about persistency and
  the like and what performance cost that has. That killed devfs in the
  end.

But even more I'd like to know wtf we don't just fix the stability of the
big block device numbering by attaching them to the existing block device
nodes using minors > 256 which are currently unused in this space.
Historically it didn't happen because Al Viro jumped up and down about
the initial proposal but its cleaner than a new devfs and it solves the
problem for everyone.

Given most distros use udev sorting udev out is obviously useful but its
not the 0.06 seconds - its the rest of the time that matters. If a sysfs
table of devices or buffering the events until it starts sorts that then
we have a far better model.

Udev tackles all the hard stuff - policy in user space, event triggering
for management etc, that your new devfs simply doesn't address. Fixing
udev isn't so much fun but it does actually get us something featureful
and useful that does what people want.

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Mon, May 11, 2009 at 15:10, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> And I did, and it's obvious that creating a single file along with the
>> ~10 we already create in /sys, instead of running through /sys or
>> /proc later and reconstruct what we missed, is always, and in every
>> case faster and simpler. It gets rid of a bunch of things we need to
>
> Arjan's numbers for sysfs are 0.06 seconds if I remember the mail
> correctly. That doesn't account for any meaningful speedup.

Sure it does. It is great, and it started a huge effort for many
people to think about the current way to do it. It is very welcome and
it counts a lot, and there is no doubt, that most of the gains we get
today are due to Arjans work in that area.

But he does not use an initramfs, and distros insist to do that. And
that basically means you need to prepare /dev two times, and also prep
the system to cope to bootup without an initramfs, because people, me
included, don't want one on their own boxes. So comparing these
numbers does not really work too well for distros which need to
support so much more than root=/dev/sda2.

>> > - That dumping more crap in kernel without policy and management is a
>> >  good idea
>>
>> What exactly do you find is "crap"? What do you mean with "management"?
>
> Device spaces have user controlled naming rules, user controlled
> permissions, user controlled labelling and the like. That is policy, and
> the administering of that is management.

I see. But that does not change at all. It's just that you can also
bring up the box without the complex management we need to do today.
That is worth so much, in case you need to rescue it. For the real
system nothing will change, but the hard dependency on userspace
starts _after_ the basics of the box are running, at a point you can
probably start fixing things. Today you always need a rescue disk.

> That was one of the things that killed devfs eventually, and it's not a
> problem your proposal or devfs solved.

Oh, that old devfs was killed for many good reasons, sure. The biggest
reason alone to kill it, was the dumb new naming scheme, which broke
everything and got us almost nothing. But it also allowed us to boot
the box without the large dependencies, that part we like to have
back, even today.

>> > - That the other proposals are worse than yours.
>>
>> I also did, in exactly this thread.
>
> Sorry, but I can't find any convincing evidence in the mails. I see
> unhelpful things like you calling Arjan's numbers "made up", despite the
> fact he has spent months working on speeding up boot and has probably the
> most detailed analysis and data sets anyone does.

No, sorry, if that reads that way. I called Eric's "seconds" made-up.
Arjan even mentioned several times in this thread that he does not
complain about the speed of udev. But we can not really compare
Arjan's numbers because he uses a "shortcut", distros can't do for a
general purpose system.

> I think you actually hit the nail on the head a lot earlier when you
> asked Arjan  "How will you solve the dynamic device numbers". Which is
> that we could fix them ....
>
> What is the real underlying concern and what problem should we fix.

Sure, I don't object, but it's far more than disks. You need to change
more subsystems using dynamic numbers. I just stated, that distros can
not go for any static nodes with the current kernel, mainly for
correctness reasons, let alone, that there are many more block devices
to boot from than sd* nodes, which you really don't want to add all of
them statically.

>  We have at least six takes on this
>
> 1.      What problem ?

The reliability on a complex userspace to bring up the basics of a
box. The speed is a nice side-effect, and was the actual motivation.
Just as all of Arjan's async work is motivated by speed, but it also
makes things more efficient, and more flexible.
As mentioned, we create 12.000 files in sysfs, now we just add 210 and
decouple the kernel initial bootup from a complex userspace
dependency, all for the sake of robustness, that is also faster and
very flexible.

> 2.      The udev userspace setup you are using sucks so fix it

I personally wrote most of the "sucking" stuff, so anybody should let
me know, what can be fixed and how.

> 3.      Udev sucks because it can't get the early boot events so has to
> do it the hard way - so queue them

No, that problem is solved by exporting all of it in sysfs already
today. But that does not provide any of the robustness and reliability
gains the kernel-provided nodes do.

> 4.      Udev sucks because it can't get the early boot events so create
> a single table for it to read

Same as 3.), solved by reading today's sysfs.

> 5.      Make the new big block numbers stable

Might be nice to have, but we still can't include all of the possible
block driver names and nodes in initramfs. Distros can just not manage
that, and don't do it today.

> 6.      Recreate devfs in a new but more clean form

I thought we did here. :)

> I don't buy take #1 so I would like to understand
>
> - Why Arjan's systems boot very fast and yours don't

Mine does too. But general purpose systems have different problems to solve.

> - Why you think sysfs changes will help when the stats say its 0.06 of a
>  second and udev is not it appears taking much time anyway

Which sysfs changes?

> - How you think you've solved the devfs problems about persistency and
>  the like and what performance cost that has. That killed devfs in the
>  end.

What problem? It will not be different from what we do today and what
udev does. It will be just more reliable, and the point userspace
dependencies to manage /dev will be later, at a point, you can already
interact with the system.

> But even more I'd like to know wtf we don't just fix the stability of the
> big block device numbering by attaching them to the existing block device
> nodes using minors > 256 which are currently unused in this space.
> Historically it didn't happen because Al Viro jumped up and down about
> the initial proposal but its cleaner than a new devfs and it solves the
> problem for everyone.

Sounds good to me, I have no objections.

> Given most distros use udev sorting udev out is obviously useful but its
> not the 0.06 seconds - its the rest of the time that matters. If a sysfs
> table of devices or buffering the events until it starts sorts that then
> we have a far better model.

Sysfs itself is already information and buffer enough today, we have
all the information we need already, I think. What changes are you
proposing here?

> Udev tackles all the hard stuff - policy in user space, event triggering
> for management etc, that your new devfs simply doesn't address. Fixing
> udev isn't so much fun

Let me know what specifically needs to be fixed, I'll do it right
away, I wrote and maintain most of it, so I should be pretty quick to
act here. I work on it almost every day, and I mostly don't find it
non-funny. :)

>  but it does actually get us something featureful
> and useful that does what people want.

Actually, many people asked for more robustness and less complexity to
bring up a box, not for more special hacks in udev, initramfs, the
boot scripts. That's what we try to solve here, and what we did, from
my perspective.

Thanks,
Kay

Re: [patch 00/13] devtmpfs patches

[Arjan van de Ven]

On Mon, 11 May 2009 16:14:28 +0200
Kay Sievers <kay.sievers@vrfy.org> wrote:

> On Mon, May 11, 2009 at 15:10, Alan Cox <alan@lxorguk.ukuu.org.uk>
> wrote:
> >> And I did, and it's obvious that creating a single file along with
> >> the ~10 we already create in /sys, instead of running through /sys
> >> or /proc later and reconstruct what we missed, is always, and in
> >> every case faster and simpler. It gets rid of a bunch of things we
> >> need to
> >
> > Arjan's numbers for sysfs are 0.06 seconds if I remember the mail
> > correctly. That doesn't account for any meaningful speedup.
> 
> Sure it does. It is great, and it started a huge effort for many
> people to think about the current way to do it. It is very welcome and
> it counts a lot, and there is no doubt, that most of the gains we get
> today are due to Arjans work in that area.
> 
> But he does not use an initramfs, and distros insist to do that. And
> that basically means you need to prepare /dev two times, and also prep

eh why?

this is the part I'm missing.
Make /dev in the initramfs, then bind-mount-move it to its final
location later. 

you ever only need to fill your tmpfs /dev once. initramfs or not.

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Mon, May 11, 2009 at 16:30, Arjan van de Ven <arjan@infradead.org> wrote:
>> But he does not use an initramfs, and distros insist to do that. And
>> that basically means you need to prepare /dev two times, and also prep
>
> eh why?
>
> this is the part I'm missing.
> Make /dev in the initramfs, then bind-mount-move it to its final
> location later.

Yeah, sure, that's what distros do, if initramfs was used.

> you ever only need to fill your tmpfs /dev once. initramfs or not.

But you do need to support non-initramfs boot on the same system too,
so you get to provide all that bootstrap logic, mount an empty /dev
and such, ... installed a second time to possibly run from the real
rootfs. That step is partly skipped if initramfs did the tmpfs thing
already, but ...

Initramfs is only used to mount the root and then you leave it behind
you as soon as you can. Only on the real root you find all the
additional udev rules, and tools, which are not available in
initramfs, and you need to re-run the coldplug to apply the
permissions, group ownership, create the configured symlinks, and run
the tools to setup devices.

All these steps involve hard checkpoints where you have to delay other
things that might need device nodes which need to be created first.
Depending on the actual boot setup where you did the bootstrap, the
checkpoint vary.

Thanks,
Kay

Re: [patch 00/13] devtmpfs patches

[Alan Cox]

> But he does not use an initramfs, and distros insist to do that. And
> that basically means you need to prepare /dev two times, and also prep

Once. You may want to move a few bits later. You only need null,
zero and console to get started. Thats three fixed device nodes. 

If we have stable block numbers you might need more than one extra if you
have to search for a UUID/label and it moved from where you cached
it. Without stable block numbers you can't cache the node but most create
lots of nodes to go looking. Do I understand that bit right ?

However you still only create it once as you have zero, console and null
on the initrd already and do

	mkdir final-dev
	mount tmpfs
	create them in final-dev
	mount root
	move final-dev

Tell me if I'm going astray here as I want to clearly understand the
problem.

Another data point: On a fairly typical PC on a single CPU we can do over
30,000 mknods per second on tmpfs. I've just benched it. So you can
create those block nodes very fast indeed.

On a 1 second budget I can create 3000 device nodes (which should cover
most user systems quite adequately) and have 0.9 seconds left to do other
work.

> > Device spaces have user controlled naming rules, user controlled
> > permissions, user controlled labelling and the like. That is policy, and
> > the administering of that is management.
> 
> I see. But that does not change at all. It's just that you can also
> bring up the box without the complex management we need to do today.

If you have an environment using any of those features then not having
that management is not a win - its a bug.

> > That was one of the things that killed devfs eventually, and it's not a
> > problem your proposal or devfs solved.
> 
> Oh, that old devfs was killed for many good reasons, sure. The biggest
> reason alone to kill it, was the dumb new naming scheme, which broke

The "naming scheme" ? It was not the naming scheme but the inability to
make it do stuff the way users wanted. If the naming scheme had been
trivially configurable then the distro would simply have shipped a
different naming scheme.

> As mentioned, we create 12.000 files in sysfs, now we just add 210 and

setfacl -m u:alan:r /sys/devices/virtual/dmi/id/bios_vendor
setfacl: /sys/devices/virtual/dmi/id/bios_vendor: Operation not supported

Sysfs doesn't even support per user ACLs which means its not much use for
tty devices or a lot of other things where you want to give access to a
piece of hardware to groups of users or use SELinux to control root more
tightly.

> decouple the kernel initial bootup from a complex userspace
> dependency, all for the sake of robustness, that is also faster and
> very flexible.

It isn't flexible. You can't set the naming policy, you can't set the
permissions, you can't control the labelling. It might be a convenient
way to implement a very specific narrow set up.

> No, that problem is solved by exporting all of it in sysfs already
> today. But that does not provide any of the robustness and reliability
> gains the kernel-provided nodes do.

What is robust and reliable about having another set of nodes that an
existing distro won't know about and existing tools don't know about that
has permissions and labels that bypass the security as configured by the
system administrator ????

> > 5.      Make the new big block numbers stable
> 
> Might be nice to have, but we still can't include all of the possible
> block driver names and nodes in initramfs. Distros can just not manage
> that, and don't do it today.

Even if we have to create a lot of nodes it shouldn't be slow - mknod
syscalls on tmpfs are as we've just established - quite acceptably quick.
Yes I think stable numbers would be smart.

> Mine does too. But general purpose systems have different problems to solve.

I'm of the opinion your system isn't general purpose - its Kay purpose.
If it can become truely general purpose and replace or improve udev with
something far better then great but can it ?

> > - Why you think sysfs changes will help when the stats say its 0.06 of a
> >  second and udev is not it appears taking much time anyway
> 
> Which sysfs changes?

(Sorry that was Eric I think)
> 
> > - How you think you've solved the devfs problems about persistency and
> >  the like and what performance cost that has. That killed devfs in the
> >  end.
> 
> What problem? 

The problem I've been pointing out all along - security, naming,
permissions, persistency.

> Let me know what specifically needs to be fixed, I'll do it right
> away, I wrote and maintain most of it, so I should be pretty quick to
> act here. I work on it almost every day, and I mostly don't find it
> non-funny. :)

So if you maintain it why is it so slow ? (that isn't an accusation of
incompetence btw I want to understand the bottlenecks) - what percentage
is CPU wait, what is I/O wait, wtf are we doing with all that wall time
and serialized probing ? You've still not provided any useful data on
timings. If you had four or five pet programmers and were told "fix udev"
what would you direct them to sort out ? The numbers you've posted
contain no breakdown. Yes its faster than the old system for your
specific case but there is no "why" in the data.

There isn't any reason it should magically go faster in kernel. We don't
run the CPU at a different speed in kernel and syscalls are cheap.

> >  but it does actually get us something featureful
> > and useful that does what people want.
> 
> Actually, many people asked for more robustness and less complexity to
> bring up a box, not for more special hacks in udev, initramfs, the
> boot scripts. That's what we try to solve here, and what we did, from
> my perspective.

"from my perspective" - bingo...

Which is the devfs problem - its easy to solve a problem for one
perspective or one user only. But we'd have an awful lot of devfs clones
in the kernel if we kept doing that.

So I'd like
 - my device file system to do SELinux and ACLs (and Tomoyo and ...)
 - ability to set labels and security contexts and permissions
 - device nodes in one place only
 - ability to use security models which take stuff away from root (so
   chmodding the sysfs node 000 doesn't cut the mustard)
 - a guarantee I can't race the policy application and node creation on
   hotplug. In other words the creator sets up its security contexts and
   the like then does the node create.

Putting device nodes into sysfs can't do most if any of that

Putting the data to create those initial device nodes into sysfs *can*
make it customisable this way. It also means your initrd can be more
robust because the device creation logic is very very simple.

sh < /sys/initial-device-list

might be slightly extreme but you need little more when not using fancy
feature sets. We've just established by benchmarking that the mknod paths
are fast enough.

It's a question of API and layering

If you put the devices into sysfs I get burger and fries the way you like
If you put the list of devices into sysfs I get to decide how I want it.

We have enough fixed nodes to run a recovery shell in the initrd or boot
with init=/bin/sh so the recovery argument doesn't seem to hold water.

The performance for reading one sysfs file (even without sysfs
optimisation) and writing 3000 device nodes to disk is more than
acceptable so if you don't mind I'd prefer my burger with extra onions ;)

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Mon, May 11, 2009 at 17:53, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> But he does not use an initramfs, and distros insist to do that. And
>> that basically means you need to prepare /dev two times, and also prep
>
> Once. You may want to move a few bits later. You only need null,
> zero and console to get started. Thats three fixed device nodes.

And random, rtc, tty for a custom console, and whatever not, in the
non-trivial case. Not to mention non-x86 boxes.

> If we have stable block numbers you might need more than one extra if you
> have to search for a UUID/label and it moved from where you cached
> it. Without stable block numbers you can't cache the node but most create
> lots of nodes to go looking. Do I understand that bit right ?

Look at drivers/block/, you need all of the names then, to get it
booting from a non-sd node.

> However you still only create it once as you have zero, console and null
> on the initrd already and do
>
>        mkdir final-dev
>        mount tmpfs
>        create them in final-dev
>        mount root
>        move final-dev
>
> Tell me if I'm going astray here as I want to clearly understand the
> problem.

Maybe your root disk shows up after the "create them in final-dev"?

Initramfs logic works by just waiting for the device node udev creates
asynchronously. When it's there, we go ahead. To make sure you don't
miss it, you have to start udev before you copy the nodes over.

> Another data point: On a fairly typical PC on a single CPU we can do over
> 30,000 mknods per second on tmpfs. I've just benched it. So you can
> create those block nodes very fast indeed.
>
> On a 1 second budget I can create 3000 device nodes (which should cover
> most user systems quite adequately) and have 0.9 seconds left to do other
> work.

Sure. But that does not solve the problem of missing device nodes or
the requirement of shipping all possible combinations.

>> > Device spaces have user controlled naming rules, user controlled
>> > permissions, user controlled labelling and the like. That is policy, and
>> > the administering of that is management.
>>
>> I see. But that does not change at all. It's just that you can also
>> bring up the box without the complex management we need to do today.
>
> If you have an environment using any of those features then not having
> that management is not a win - its a bug.

Bugs happen, it's a reality. We don't needlessly make it harder to
work around a bug. We have many tings to make the kernel
self-contained. With your argument, we should remove all partition
scanning from the kernel too.

>> > That was one of the things that killed devfs eventually, and it's not a
>> > problem your proposal or devfs solved.
>>
>> Oh, that old devfs was killed for many good reasons, sure. The biggest
>> reason alone to kill it, was the dumb new naming scheme, which broke
>
> The "naming scheme" ? It was not the naming scheme but the inability to
> make it do stuff the way users wanted. If the naming scheme had been
> trivially configurable then the distro would simply have shipped a
> different naming scheme.

Yeah, but it did not even create the current names by default. So it
was the main reason distros did not use is.

>> As mentioned, we create 12.000 files in sysfs, now we just add 210 and
>
> setfacl -m u:alan:r /sys/devices/virtual/dmi/id/bios_vendor
> setfacl: /sys/devices/virtual/dmi/id/bios_vendor: Operation not supported
>
> Sysfs doesn't even support per user ACLs which means its not much use for
> tty devices or a lot of other things where you want to give access to a
> piece of hardware to groups of users or use SELinux to control root more
> tightly.

We add the 210 to a separate tmpfs which is the subject of this mail,
and that supports ACLs just fine. We don't add any device nodes to
sysfs.

>> decouple the kernel initial bootup from a complex userspace
>> dependency, all for the sake of robustness, that is also faster and
>> very flexible.
>
> It isn't flexible. You can't set the naming policy, you can't set the
> permissions, you can't control the labelling. It might be a convenient
> way to implement a very specific narrow set up.

The kernel _is_ the naming policy already, claiming anything different
is just a lie. If you go and rename /sys/block/sda in the kernel, no
current udev system will provide a /dev/sda node anymore. It's that
since forever.

Udev still has the last say, and can overwrite the kernel policy,
nothing will change, but that does not happen today, and will not
happen in the future for 98% of the devices.

>> No, that problem is solved by exporting all of it in sysfs already
>> today. But that does not provide any of the robustness and reliability
>> gains the kernel-provided nodes do.
>
> What is robust and reliable about having another set of nodes that an
> existing distro won't know about and existing tools don't know about that
> has permissions and labels that bypass the security as configured by the
> system administrator ????

Which "other" set? There is only one set of names, that is the kernel
provided name. There is no bypass anywhere.

>> > 5.      Make the new big block numbers stable
>>
>> Might be nice to have, but we still can't include all of the possible
>> block driver names and nodes in initramfs. Distros can just not manage
>> that, and don't do it today.
>
> Even if we have to create a lot of nodes it shouldn't be slow - mknod
> syscalls on tmpfs are as we've just established - quite acceptably quick.
> Yes I think stable numbers would be smart.

Just grep in drivers/block/ and estimate how many nodes you will need
to provide. General purpose distros don't do that today, and don't
want to go back to the time they needed to that.

>> Mine does too. But general purpose systems have different problems to solve.
>
> I'm of the opinion your system isn't general purpose - its Kay purpose.
> If it can become truely general purpose and replace or improve udev with
> something far better then great but can it ?

I don't understand this question. What do you mean?

>> What problem?
>
> The problem I've been pointing out all along - security, naming,
> permissions, persistency.

Naming happens in the kernel for udev systems since forever.
Permissions happens in udev, and we keep that. All kernel created
nodes are 0600 root:root. If a device exists in the kernel, we will
see its node, if it goes away the node goes away, just like sysfs, and
just like we do with udev in /dev today.

>> Let me know what specifically needs to be fixed, I'll do it right
>> away, I wrote and maintain most of it, so I should be pretty quick to
>> act here. I work on it almost every day, and I mostly don't find it
>> non-funny. :)
>
> So if you maintain it why is it so slow ? (that isn't an accusation of
> incompetence btw I want to understand the bottlenecks) - what percentage
> is CPU wait, what is I/O wait, wtf are we doing with all that wall time
> and serialized probing ? You've still not provided any useful data on
> timings. If you had four or five pet programmers and were told "fix udev"
> what would you direct them to sort out ? The numbers you've posted
> contain no breakdown. Yes its faster than the old system for your
> specific case but there is no "why" in the data.

It isn't slow. It's just that bootstrapping/re-constructing something
later can obviously never be faster than doing it when the device is
created.

I don't know of any obvious fixes to udev, otherwise I would have
implemented them.

> There isn't any reason it should magically go faster in kernel. We don't
> run the CPU at a different speed in kernel and syscalls are cheap.

Yes, we are in the context of the device, and create the node on top
of many other things we do. At the time userspace runs, we need to
recover all that information, which is not as robust, and not as
cheap. The recover/bootstrap point is a hard blocking point for other
stuff that can run at the same time otherwise.

>> >  but it does actually get us something featureful
>> > and useful that does what people want.
>>
>> Actually, many people asked for more robustness and less complexity to
>> bring up a box, not for more special hacks in udev, initramfs, the
>> boot scripts. That's what we try to solve here, and what we did, from
>> my perspective.
>
> "from my perspective" - bingo...

Sure, what else can I say, I have only my one, just like you have yours.

> Which is the devfs problem - its easy to solve a problem for one
> perspective or one user only. But we'd have an awful lot of devfs clones
> in the kernel if we kept doing that.
>
> So I'd like
>  - my device file system to do SELinux and ACLs (and Tomoyo and ...)
>  - ability to set labels and security contexts and permissions
>  - device nodes in one place only
>  - ability to use security models which take stuff away from root (so
>   chmodding the sysfs node 000 doesn't cut the mustard)
>  - a guarantee I can't race the policy application and node creation on
>   hotplug. In other words the creator sets up its security contexts and
>   the like then does the node create.

You can do all that just like you do today, no change at all.

> Putting device nodes into sysfs can't do most if any of that

Nobody talked about that.

> Putting the data to create those initial device nodes into sysfs *can*
> make it customisable this way. It also means your initrd can be more
> robust because the device creation logic is very very simple.
>
> sh < /sys/initial-device-list

And you still need to cope with the races, and bring up the event
listener before that. This is less reliable and always slower than the
kernel provided nodes, besides that your /sys/initial-device-list will
be the same amount of code we need for the node creation right away,
without any of the other benefits, and will require another
special-case tool we don't use today.

> might be slightly extreme but you need little more when not using fancy
> feature sets. We've just established by benchmarking that the mknod paths
> are fast enough.
>
> It's a question of API and layering
>
> If you put the devices into sysfs I get burger and fries the way you like
> If you put the list of devices into sysfs I get to decide how I want it.

Come on, nobody puts nodes in sysfs. Where did you get that idea from?

> We have enough fixed nodes to run a recovery shell in the initrd or boot
> with init=/bin/sh so the recovery argument doesn't seem to hold water.

Unless you got a box that does not work anymore, than it's the most
important thing you can have.

> The performance for reading one sysfs file (even without sysfs
> optimisation) and writing 3000 device nodes to disk is more than
> acceptable so if you don't mind I'd prefer my burger with extra onions ;)

Sure, if I can have a beer too. :)

Thanks,
Kay

Re: [patch 00/13] devtmpfs patches

[Arjan van de Ven]

On Mon, 11 May 2009 18:28:20 +0200
Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> It isn't slow. It's just that bootstrapping/re-constructing something
> later can obviously never be faster than doing it when the device is
> created.

the performance gains from doing stuff in batches is obviously well
established; CPU caches cause that. Not saying that's a hot factor
here, the total only takes 0.01 second after all, but "obviously" isn't
true here.


> I don't know of any obvious fixes to udev, otherwise I would have
> implemented them.

there's not much to fix afaics. It'd be nice if it was the 0.06 seconds
that Eric gets, but 0.20 isn't all that bad either.

> > sh < /sys/initial-device-list
> 
> And you still need to cope with the races, and bring up the event
> listener before that. 

so ?

> This is less reliable and always slower than the
> kernel provided nodes, besides that your /sys/initial-device-list will
> be the same amount of code we need for the node creation right away,
> without any of the other benefits, and will require another
> special-case tool we don't use today.

it's not about the amount of code. It's about in how many useful ways
the code can be used!

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Mon, May 11, 2009 at 18:41, Arjan van de Ven <arjan@infradead.org> wrote:
> On Mon, 11 May 2009 18:28:20 +0200
> Kay Sievers <kay.sievers@vrfy.org> wrote:
>>
>> It isn't slow. It's just that bootstrapping/re-constructing something
>> later can obviously never be faster than doing it when the device is
>> created.
>
> the performance gains from doing stuff in batches is obviously well
> established; CPU caches cause that. Not saying that's a hot factor
> here, the total only takes 0.01 second after all, but "obviously" isn't
> true here.

I'm just saying that we don't need any batch, we are in the context of
the device and can do the work there, while we are doing much more and
similar stuff anyway. You can apply your cache argument there too,
because the iterator for your list would need to get the context of
every device first, and we have that already.

>> I don't know of any obvious fixes to udev, otherwise I would have
>> implemented them.
>
> there's not much to fix afaics. It'd be nice if it was the 0.06 seconds
> that Eric gets, but 0.20 isn't all that bad either.

Good.

>> > sh < /sys/initial-device-list
>>
>> And you still need to cope with the races, and bring up the event
>> listener before that.
>
> so ?

As said, you need to listen to events before you look what's already
there, otherwise you may miss stuff in-between, and you might wait for
exactly that event.

The same applies when you leave initiramfs, the in-initramfs udevd
copy is killed, and the one from the real root is started. You may
miss events in-between, and need to run a full coldplug again, not
only to apply the policy, but also to make sure that all nodes are
there. The policy can run in the background for most things just fine,
the missing node may cause trouble.

>> This is less reliable and always slower than the
>> kernel provided nodes, besides that your /sys/initial-device-list will
>> be the same amount of code we need for the node creation right away,
>> without any of the other benefits, and will require another
>> special-case tool we don't use today.
>
> it's not about the amount of code. It's about in how many useful ways
> the code can be used!

Yeah, and I mentioned many other ways this is useful, to do stuff in
parallel, to be able to rescue, and to have custom systems which do
not need a full udev at all, where many embedded systems use mbox,
which can be made much simpler.

Thanks,
Kay

Re: [patch 00/13] devtmpfs patches

[Alan Cox]

> The same applies when you leave initiramfs, the in-initramfs udevd
> copy is killed, and the one from the real root is started. You may
> miss events in-between, and need to run a full coldplug again, not
> only to apply the policy, but also to make sure that all nodes are
> there. The policy can run in the background for most things just fine,
> the missing node may cause trouble.

What a strange behaviour. Why not run a single udev instance inside the
tmpfs you are turning into dev and will then attach to the real rootfs
when it appears ? You only need to build /dev once.

> Yeah, and I mentioned many other ways this is useful, to do stuff in
> parallel, to be able to rescue, and to have custom systems which do

But there are lots where it is not - and those you've mentioned where it
might be seem rather stretched at best.

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Mon, May 11, 2009 at 19:55, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> The same applies when you leave initiramfs, the in-initramfs udevd
>> copy is killed, and the one from the real root is started. You may
>> miss events in-between, and need to run a full coldplug again, not
>> only to apply the policy, but also to make sure that all nodes are
>> there. The policy can run in the background for most things just fine,
>> the missing node may cause trouble.
>
> What a strange behaviour. Why not run a single udev instance inside the
> tmpfs you are turning into dev and will then attach to the real rootfs
> when it appears ? You only need to build /dev once.

Because the udev in initramfs has no clue about uid/gid, has not the
tools it needs for a full setup, has not the same rules as the one in
the real root. Ignoring the fact, that people may run different
versions in initramfs and the real root. There is no sane option so
far, not to replace the udevd process from initramfs.

>> Yeah, and I mentioned many other ways this is useful, to do stuff in
>> parallel, to be able to rescue, and to have custom systems which do
>
> But there are lots where it is not - and those you've mentioned where it
> might be seem rather stretched at best.

Right, but the information you need for all other use cases is already
there today in /sys. This is about something new, so there is not a
competition about features, just an option to solve a problem in a
different way, which we prefer over the current one.

Thanks,
Kay

Re: [patch 00/13] devtmpfs patches

[Alan Cox]

> Right, but the information you need for all other use cases is already
> there today in /sys. This is about something new, so there is not a
> competition about features, just an option to solve a problem in a
> different way, which we prefer over the current one.

"we". You don't speak for me or a lot of people on this one.

Running a second udevd seems to be overkill. You know which nodes you've
created so far so you know which series of rules to reapply.

> just an option to solve a problem in a different way

There are thousands of kernel contributors. If they all submit everything
that solves their problem, their way we'd drown in the resulting mess.
devfs was Richard Gooch's way perhaps we should add that back as well,
and a variant that uses a data file for me, and a different one for Arjan.

We could let everyone invent new arbitary APIs for all their device
drivers so you need a different app for each pointing device or
each light level sensor ....

That way lies *madness*.

Re: [patch 00/13] devtmpfs patches

[Alan Cox]

> > Once. You may want to move a few bits later. You only need null,
> > zero and console to get started. Thats three fixed device nodes.
> 
> And random, rtc, tty for a custom console, and whatever not, in the
> non-trivial case. Not to mention non-x86 boxes.

Don't need those initially. But they are static so no cost.

> Maybe your root disk shows up after the "create them in final-dev"?

Doesn't matter if it does. I'm going to attach the tmpfs when it
eventually turns up, and in the case where I'm still waiting for it I do
not have a performance problem by definition.

> > On a 1 second budget I can create 3000 device nodes (which should cover
> > most user systems quite adequately) and have 0.9 seconds left to do other
> > work.
> 
> Sure. But that does not solve the problem of missing device nodes or
> the requirement of shipping all possible combinations.

Yes it does. If I have an enumerable list of what is present then I have
lots of time to turn that list into nodes. The only thing that matters is
the list. It doesn't matter if I do

	get static list
	open listener port
	create static list
	go from listener

or

	open listener port (buffered from boot time)
	go from listener

conceptually thats simply

	script <pipe

with the other end of the pipe the kernel. That's pretty fast be it
netlink or whatever.

> > If you have an environment using any of those features then not having
> > that management is not a win - its a bug.
> 
> Bugs happen, it's a reality. We don't needlessly make it harder to
> work around a bug. We have many tings to make the kernel

You are *introducing* a bug, your very design is faulty as it can't do
what users need and what udev can.

> self-contained. With your argument, we should remove all partition
> scanning from the kernel too.

I would really like to do that because it causes untold pain with faulty
devices and also on SAN networks. However we have to have a workable
migration path for it. It's on the long term todo list and as md matures
it becomes the natural path. It also trivially makes partition scanning
asynchronous. Right now the partition code can prevent you booting a
machine with a failed device and in a few cases actually stop you
recovering the media.

> We add the 210 to a separate tmpfs which is the subject of this mail,
> and that supports ACLs just fine. We don't add any device nodes to
> sysfs.

>From user space I can create 30,000 tmpfs nodes a second so why exactly
must the kernel do this for me. In the case you are trying to replace I
have to do the following

	read one message from the kernel (one syscall - could even get
	batching so its < 1)
	parse it (on a 1GHz plus processor with the data in cache)
	make one setfsuid sycall
	make one mknod syscall

> The kernel _is_ the naming policy already, claiming anything different
> is just a lie. If you go and rename /sys/block/sda in the kernel, no
> current udev system will provide a /dev/sda node anymore. It's that
> since forever.

Permissions, selinux labels, acls ? The kernel is none of those, even if
it dabbles a bit more than it should in naming policy. Not everyone btw
slavishly follows the kernel naming policy.

> Udev still has the last say, and can overwrite the kernel policy,

*overwrite* - this is racy. In the secure system case the initial policy
has to have the right labels and security.

> nothing will change, but that does not happen today, and will not
> happen in the future for 98% of the devices.

Even if I agreed with you then the other 2% of the Linux userbase is
millions of devices....

> Just grep in drivers/block/ and estimate how many nodes you will need
> to provide. General purpose distros don't do that today, and don't
> want to go back to the time they needed to that.

I only need to provide those that are present but I must have a way of
getting the list of what is present.

> Naming happens in the kernel for udev systems since forever.
> Permissions happens in udev, and we keep that. All kernel created
> nodes are 0600 root:root. If a device exists in the kernel, we will

0600 root:root isn't sufficient for a secure environment

> see its node, if it goes away the node goes away, just like sysfs, and
> just like we do with udev in /dev today.

That also isn't sufficient for a secure environment.

> It isn't slow. It's just that bootstrapping/re-constructing something
> later can obviously never be faster than doing it when the device is
> created.

But that doesn't imply it has to be done in kernel space ? Caring about
speed is one thing but here are some other speed ups we could trivially do

- turn off memory protection
- stop supporting paging/swap
- require co-operative multi-tasking

Speed is not everything you have to balance speed, flexibility (that
means real flexibility not 'hey it does everything *I* want')

In this case the difference between the kernel creating the node and
userspace turning a message into a node is utterly miniscule. If it isn't
then *that* needs fixing.

Creating the device nodes from the kernel as devfs showed us before isn't
the right interface.

> > "from my perspective" - bingo...
> Sure, what else can I say, I have only my one, just like you have yours.

Yep and the kernel has to be the sum of a lot of perspectives, not "and
screw you" to the 2% who are inconvenient.

> > So I'd like
> >  - my device file system to do SELinux and ACLs (and Tomoyo and ...)
> >  - ability to set labels and security contexts and permissions
> >  - device nodes in one place only
> >  - ability to use security models which take stuff away from root (so
> >   chmodding the sysfs node 000 doesn't cut the mustard)
> >  - a guarantee I can't race the policy application and node creation on
> >   hotplug. In other words the creator sets up its security contexts and
> >   the like then does the node create.
> 
> You can do all that just like you do today, no change at all.

No I can't because you create nodes root:root:0600 with no labels before
I can get at them.

> > sh < /sys/initial-device-list
> 
> And you still need to cope with the races, and bring up the event
> listener before that. This is less reliable and always slower than the

Or buffer the events instead - trivial enough

> kernel provided nodes, besides that your /sys/initial-device-list will

But it is vastly more flexible, handles permissions properly and does
what everyone needs as well as fixing the races.

> > If you put the devices into sysfs I get burger and fries the way you like
> > If you put the list of devices into sysfs I get to decide how I want it.
> 
> Come on, nobody puts nodes in sysfs. Where did you get that idea from?

s/sysfs/tmpfs/
> 
> > We have enough fixed nodes to run a recovery shell in the initrd or boot
> > with init=/bin/sh so the recovery argument doesn't seem to hold water.
> 
> Unless you got a box that does not work anymore, than it's the most
> important thing you can have.

If my box is so busted that the initrd shell (busybox I would
pick), /dev/zero and /dev/console are missing then I am so screwed that I
will need rescue media or to have a "safe mode" alternative kernel boot
already in the grub menu.. which I have even if the distros can't figure
out that one.

> > The performance for reading one sysfs file (even without sysfs
> > optimisation) and writing 3000 device nodes to disk is more than
> > acceptable so if you don't mind I'd prefer my burger with extra onions ;)
> 
> Sure, if I can have a beer too. :)

Well I'm sorry I hardcoded a lack of beer into the serial layer to save a
microsecond, you'll have to go without.... It works for me so clearly
your usage pattern isn't interesting.

See the problem ?

Alan

Re: [patch 00/13] devtmpfs patches

[Eric W. Biederman]

Kay Sievers <kay.sievers@vrfy.org> writes:

>> Yes but you are asking all of us to maintain it.  Forever in perpetuity.
>> A better case needs to be made than you have already shipped the code.
>
> I would be very careful with such statement if you want us to accept
> your namespace hacks in the future. I guess if we ask with your next
> round "do we want to to have to maintain this for forever" you get a
> very different answer than today.

I fully expect people to ask if we want people to maintain my code
forever.

I need to extend to you a small apology you were blasting Arjan and
had added me to the CC, and I thought it was a reply to something I
wrote so my context was wrong, and I reacted more strongly than I
would have otherwise.

>> I don't see a case having been made that the existing user
>> space interface is broken.  Just that the udev implementation
>> is slow.
>
> That's utter nonsense. It's not slow at all, it's just slower that
> what we can do with the bit of help from the kernel.

Which has been my question all along where is the kernel slow?

>> I think a slow user space application is simply not a justification
>> for putting code in the kernel.
>
> Can you read? Did you read the many reasons why we want this? I guess not.

I see statements like:
"several seconds" (Your original patch)
"boot speed boot speed boot speed" (You)
"1-2 seconds" (GregKH)

And I got the impression that a very slowly running udev is what you
are trying to solve.

Your numbers actually only show a 1 second net gain on kvm.  Although
it is hard to tell what is happening.

It sounds like what you are really trying to solve is to allow more
things to run in parallel with udev.  I believe there is a very simple
way to do that.

At udevd start.
mount /dev
mknod /dev/console
mknod /dev/zero
mknod /dev/null
(and maybe a few other well know device nodes)
daemonize (to stop serializing other processes)
dynamically create everything else by looking at sysfs.

That should have a trivial serialized cost, and allow you to take
whatever time it is you need to serialize device creation.

It has the downside that it opens up the window between when devices
are in sysfs and devices are in /dev, but I don't see it creating
any new races.

Eric

Re: [patch 00/13] devtmpfs patches

[Arjan van de Ven]

On Mon, 11 May 2009 03:22:53 +0200
Kay Sievers <kay.sievers@vrfy.org> wrote:

> On Mon, May 11, 2009 at 02:00, Arjan van de Ven <arjan@infradead.org>
> wrote:
> > (and it seems to be irrelevant to the devtmpfs discussion anyway
> > since Eric Biederman has shown that pulling the device numbers out
> > of sysfs is basically free... even though it'd be nice to give that
> > some help to make it a nice index)
> 
> It's not free, and it's racy to just copy over the stuff. You have to
> subscribe to events _before_ you start reading /sys and create nodes,
> to catch the new stuff that comes in in the meantime. You have to
> mount an empty tmpfs, bring up a udevd-like process to subscribe to
> events for new devices and create nodes for them, create the nodes for
> the already existing devices found in /sys. That's all far from
> "free", and has non-trivial dependencies.
> 

How about we do something that is useful for more scenarios instead,
like proposed already? A /proc or similar file that just lists the
type,major,minor and name for the known nodes.
This has none of the race issues you mention (since udev still later
processes the events) but opens a LOT of flexibility. You could use it
in your set up, but I could use it in the Moblin setup as well.
And I suspect many other setups suddenly become possible, just because
there now is a lost of device nodes that are "active". Debugging
drivers, etc etc. Long list.

I sort of get a bad taste in my mouth from this thread to be honest;
it really feels like "this is the code that HAS to be pushed", rather
than working on getting something useful for a wide set of uses... even
if it's not your initial implementation. 

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [patch 00/13] devtmpfs patches

[Fabio Comolli]

Hi

On Mon, May 11, 2009 at 3:22 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
[BIG snip]
> Devtmpfs is the simplest, is the fastest, is the most reliable, and it
> is the most flexible option for us. And still, nobody will be forced
> to use it, it's entirely optional. For our systems, we decided to do
> it that way, and we ship it already in the distro, and if there are no
> substantial problems coming up, which we don't expect, we will
> continue using it.

Can you please point me to a SuSE kernel that ships with this new feature?
Thanks,
Fabio

Re: [patch 00/13] devtmpfs patches

[Greg KH]

On Mon, May 11, 2009 at 01:49:03PM +0200, Fabio Comolli wrote:
> Hi
> 
> On Mon, May 11, 2009 at 3:22 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> [BIG snip]
> > Devtmpfs is the simplest, is the fastest, is the most reliable, and it
> > is the most flexible option for us. And still, nobody will be forced
> > to use it, it's entirely optional. For our systems, we decided to do
> > it that way, and we ship it already in the distro, and if there are no
> > substantial problems coming up, which we don't expect, we will
> > continue using it.
> 
> Can you please point me to a SuSE kernel that ships with this new feature?

It's in the FACTORY tree right now, and will be shown publically in a
few weeks at some trade shows.

thanks,

greg k-h

Re: [patch 00/13] devtmpfs patches

[Eric W. Biederman]

Kay Sievers <kay.sievers@vrfy.org> writes:

> Maybe you should just give it a try, apply the patch, and bring it up
> on a box with init=/bin/sh, look at /dev, load some modules and look
> at /dev again - and see the beauty. I'm pretty sure, when you've seen
> it for real, you never want to go back to static nodes or whatever
> other bad hacks to bootstrap /dev.

After it sunk in what you had said I had to go look at your patch.
You do magically and backwards incompatibly mount on top of /dev.

That part does not work, and who knows what static /dev setup you break.

The goal for kernel compile options is that they do not affect the
kernels behavior.  The behavior in devmtmpfs clearly does not match
that rule.  The kernel acts very different with it compiled in
and with it not compiled in. So that section of the code deserves.

Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>

+/* After the root filesystem is mounted by the kernel at /root, or the
+ * initramfs in extracted at /root, this tmpfs will be mounted at /root/dev.
+ */
+int devtmpfs_mount(const char *mountpoint)
+{
+	struct path path;
+	int err;
+
+	if (!dev_mnt)
+		return 0;
+
+	err = kern_path(mountpoint, LOOKUP_FOLLOW, &path);
+	if (err)
+		return err;
+	err = do_add_mount(dev_mnt, &path, 0, NULL);
+	if (err)
+		printk(KERN_INFO "devtmpfs: error mounting %i\n", err);
+	else
+		printk(KERN_INFO "devtmpfs: mounted\n");
+	path_put(&path);
+	return err;
+}
+

--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -414,7 +414,7 @@ void __init prepare_namespace(void)
 
 	mount_root();
 out:
+	devtmpfs_mount("dev");
 	sys_mount(".", "/", NULL, MS_MOVE, NULL);
 	sys_chroot(".");
 }
-

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Mon, May 11, 2009 at 18:40, Eric W. Biederman <ebiederm@xmission.com> wrote:
> The goal for kernel compile options is that they do not affect the
> kernels behavior.  The behavior in devmtmpfs clearly does not match
> that rule.  The kernel acts very different with it compiled in
> and with it not compiled in. So that section of the code deserves.

It's the same as with any other option, like the ones that enable
dynamic minors.

Kay

Re: [patch 00/13] devtmpfs patches

[Eric W. Biederman]

Kay Sievers <kay.sievers@vrfy.org> writes:

> On Mon, May 11, 2009 at 18:40, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> The goal for kernel compile options is that they do not affect the
>> kernels behavior.  The behavior in devmtmpfs clearly does not match
>> that rule.  The kernel acts very different with it compiled in
>> and with it not compiled in. So that section of the code deserves.
>
> It's the same as with any other option, like the ones that enable
> dynamic minors.

No it's not.

The practical goal is that a distribution can enable essentially every feature
in the kernel and not be forced to use one.

The most similar example I can think of is the dhcp client in the kernel.
Even when compiled in only if you enable it on the command line (aka ip=dhcp)
does it enable and attempt to network boot.

Mouting on /dev might be sane if it was enabled by a kernel command line option.
By default it is wrong.

Dynamic minors is right on that hairy edge.  I'm puzzled know why we
can't have the first N devices use the static assignment and the rest
of the devices use the dynamic minors.

Eric

Re: [patch 00/13] devtmpfs patches

[Andrew Morton]

On Mon, 11 May 2009 01:47:16 +0200 Kay Sievers <kay.sievers@vrfy.org> wrote:

> On Sun, May 10, 2009 at 23:19, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >> /me boggles, however does one end up with that many partitions on so few
> >> disks?
> >
> > It happens. Tejun did the extending because libata users were really
> > hitting these limits.
> >
> >> /boot
> >> /
> >> /home
> >> /usr
> >> swap
> >> /usr/local
> >> /opt
> >>
> >> and I'm seriously out of sensible ideas.
> >
> > I've seen two usual variants
> >
> > __ __ __ __Fedora & Unbuntu & Debian & ....
> >
> > __ __ __ __Fedora 10 & Rawhide & Fedora 9 & ...
> >
> > for people who like to play with distros or need to test a product on them
> >
> > and once you do that 16 is quite easy
> 
> That's right. Also people with virtualization, running many guest from
> individual partitions, like to do that - and 16 is nothing for them.
> :)
> 
> Some of us run the dynamic sd minors already, and it's not unlikely we
> will enable it pretty soon for the distro.

There are plenty of setups which have lots of partitions, but very very
few of them are booted with any frequency.

The patchset is described as saving "a few seconds" when booting a
typical distro installation?  Out of what, 100 seconds?  That's pretty
thin gruel, IMO, and doesn't obviously justify mucking up the kernel. 

A 1.5 second saving on some gadget which boots in 6 seconds would be a
lot more interesting.

Re: [patch 00/13] devtmpfs patches

[Arjan van de Ven]

On Sun, 10 May 2009 18:00:18 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> A 1.5 second saving on some gadget which boots in 6 seconds would be a
> lot more interesting.

udev does not take 1.5 seconds today; it takes more like 0.75, of which
the last 2/3rds are optional/asynchronous.

Eric has shown that just making the nodes is 0.06 seconds with todays
sysfs interface, and there is room for improvement, and room for Kay
and Greg's patches if they get turned into having a nice flat ascii
file that lists all device nodes in the system. That way Kay and Greg
get the fast and easy startup of /dev that they want, and others like
Eric and me get the flexibility to have a slightly smarter program that
also gets the device ownership and permissions from a small database.



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [patch 00/13] devtmpfs patches

[Greg KH]

On Sun, May 10, 2009 at 06:00:18PM -0700, Andrew Morton wrote:
> On Mon, 11 May 2009 01:47:16 +0200 Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > On Sun, May 10, 2009 at 23:19, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > >> /me boggles, however does one end up with that many partitions on so few
> > >> disks?
> > >
> > > It happens. Tejun did the extending because libata users were really
> > > hitting these limits.
> > >
> > >> /boot
> > >> /
> > >> /home
> > >> /usr
> > >> swap
> > >> /usr/local
> > >> /opt
> > >>
> > >> and I'm seriously out of sensible ideas.
> > >
> > > I've seen two usual variants
> > >
> > > __ __ __ __Fedora & Unbuntu & Debian & ....
> > >
> > > __ __ __ __Fedora 10 & Rawhide & Fedora 9 & ...
> > >
> > > for people who like to play with distros or need to test a product on them
> > >
> > > and once you do that 16 is quite easy
> > 
> > That's right. Also people with virtualization, running many guest from
> > individual partitions, like to do that - and 16 is nothing for them.
> > :)
> > 
> > Some of us run the dynamic sd minors already, and it's not unlikely we
> > will enable it pretty soon for the distro.
> 
> There are plenty of setups which have lots of partitions, but very very
> few of them are booted with any frequency.

On the contrary, opensuse had lots of very grumpy users that had 10s of
partitions (lots of operating systems installed for testing and for
other reasons), that did not like us switching to libata which rendered
their partition setup as broken.

Hence the dynamic minors for large numbers of scsi partitions.  That
option is now enabled in the openSUSE FACTORY tree which made that user
group very happy.

> The patchset is described as saving "a few seconds" when booting a
> typical distro installation?  Out of what, 100 seconds?

5-8 seconds.

> That's pretty thin gruel, IMO, and doesn't obviously justify mucking
> up the kernel. 

No, it's a very large percentage overall.

Others are talking about getting a full Linux install up and running in
2 or less seconds, so every little bit counts now.

> A 1.5 second saving on some gadget which boots in 6 seconds would be a
> lot more interesting.

That is what we are talking about here.

thanks,

greg k-h

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Sat, May 9, 2009 at 17:22, Arjan van de Ven <arjan@infradead.org> wrote:
> On Sat, 9 May 2009 08:08:53 -0700
> Greg KH <gregkh@suse.de> wrote:
>
>> > Well, guess you meant the opposite ;-)
>>
>> Heh, yes, sorry about that.  It makes booting faster :)
>
> .. and I don't buy that.

Don't buy, just try it - and you will see. :)

We must mount a tmpfs at some point during bootup, wherever you do
that, in initramfs or the real root. Doing that, there will obviously
be a point, where /dev is empty, exactly at that time you can not do
anything else, which is not very tightly controlled, you can not just
start stuff in parallel during that time. Devtmpfs gets rid of that
limitation, and offers you to do things without waiting for a hard
checkpoint. It's obviously the fastest one can do, like number can
show. There can be no faster alternatives for this implemented in
userspace.

> The only argument I've heard is "oh but it's hard". No it's not.
> The other argument is "but for more partitions we get other device
> numbers"... you know what, that's easy to fix. Just make the 32 bit dev
> number consistent. Few lines of code I bet, and it is benefit for
> everyone to do that....

And all the other subsystems. You can't even trust a single static
node for rtc devices, and so on ... Converting all of that stuff in
the kernel is just not a real option. Static device nodes a bad hack,
and distros do not do that today, and can for reasons of correctness
and reliability, not start doing that.

> Beyond that... this is not needed... but at least call it "devfs".. for
> what it is.
>
> (and yes there is very obvious irony)

No problem, it's just a random name we've choosen, that even contains
all of "devfs". :) I just liked to express, that one can do whatever
one wants to do with the nodes from userspace, just like we can today.

Thanks,
Kay

Re: [patch 00/13] devtmpfs patches

[Alan Cox]

On Sat, 9 May 2009 18:46:10 +0200
Kay Sievers <kay.sievers@vrfy.org> wrote:

> On Sat, May 9, 2009 at 17:22, Arjan van de Ven <arjan@infradead.org> wrote:
> > On Sat, 9 May 2009 08:08:53 -0700
> > Greg KH <gregkh@suse.de> wrote:
> >
> >> > Well, guess you meant the opposite ;-)
> >>
> >> Heh, yes, sorry about that.  It makes booting faster :)
> >
> > .. and I don't buy that.
> 
> Don't buy, just try it - and you will see. :)

Got some boot timing graphs for the change ?

Alan

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Sat, May 9, 2009 at 19:11, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Sat, 9 May 2009 18:46:10 +0200
> Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> On Sat, May 9, 2009 at 17:22, Arjan van de Ven <arjan@infradead.org> wrote:
>> > On Sat, 9 May 2009 08:08:53 -0700
>> > Greg KH <gregkh@suse.de> wrote:
>> >
>> >> > Well, guess you meant the opposite ;-)
>> >>
>> >> Heh, yes, sorry about that.  It makes booting faster :)
>> >
>> > .. and I don't buy that.
>>
>> Don't buy, just try it - and you will see. :)
>
> Got some boot timing graphs for the change ?

So far, I got numbers for different options used with devtmpfs to
compare initramfs with non-initramfs. Initramfs is what all general
purpose distros need to use today, to be able to identify the disk by
LABEL/UUID/Hardware-properties. And I wanted to see how expensive the
use of initramfs is. They are posted here:
  http://lkml.org/lkml/2009/5/6/197

The "init" for intramfs is attached to the mail, mainly to illustrate
the simplification over the things we need to do today, and that there
is never a point in time where we have to delay things, because /dev
is empty during the moment we mount a fresh and empty tmpfs /dev.

To directly compare numbers for devtmpfs and non-devtmpfs, the "init"
script would need to be modified to ignore the kernel provided
devtmpfs and mount an empty tmpfs over it, and populate it, just like
we do it today. There is no theoretical chance that this can ever be
faster.

Most of the bootstrap logic we have today: mount an empty tmpfs /dev
-> add the few mandatory nodes to be able to start the bootstrap
process -> run something that reads sysfs-device-information (in the
usual case udev) -> delaying all further processing until /dev is
minimally usable to start things that rely on a working /dev, ... all
that gets basically stripped down to: "mount --move /dev /root/dev",
right at the end before we leave initramfs behind us.

Kay

Re: [patch 00/13] devtmpfs patches

[David P. Quigley]

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

I took the patches and applied them to Linus' tree and installed the
kernel on a Fedora 10 box with SELinux enabled and it oopses on startup.
The oops happens every time I boot up so I can reproduce it as needed to
help fix it. I've attached my kernel config in case that helps and have
pasted the oops below. If needed I can provide the entire dmesg output.

Dave

BUG: Dentry ffff88012b4043c0{i=4,n=/} still in use (-1) [unmount of tmpfs tmpfs]
------------[ cut here ]------------
kernel BUG at fs/dcache.c:669!
invalid opcode: 0000 [#1] SMP 
last sysfs file: /sys/devices/virtual/net/virbr0/bridge/stp_state
CPU 3 
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat sco bridge stp bnep l2cap bluetooth ppdev parport_pc parport sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq freq_table dm_multipath uinput snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd e1000e i2c_i801 soundcore i2c_core serio_raw snd_page_alloc pcspkr dcdbas iTCO_wdt iTCO_vendor_support [last unloaded: microcode]
Pid: 2342, comm: mingetty Not tainted 2.6.30-rc5 #1 OptiPlex 755                 
RIP: 0010:[<ffffffff810df875>]  [<ffffffff810df875>] shrink_dcache_for_umount_subtree+0x1ac/0x275
RSP: 0018:ffff88012111f848  EFLAGS: 00010292
RAX: 0000000000000054 RBX: ffff88012b4043c0 RCX: 0000000000020000
RDX: 00000000ffffffff RSI: 0000000000000082 RDI: 0000000000000246
RBP: ffff88012111f888 R08: 0000000000000002 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000018600 R12: ffff88012b4043c0
R13: 00000000000000d1 R14: ffff88012b4044e0 R15: ffffffff815f7c40
FS:  00007f569bb196f0(0000) GS:ffff880028073000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000035a84fc100 CR3: 0000000121c3b000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process mingetty (pid: 2342, threadinfo ffff88012111e000, task ffff8801261f1700)
Stack:
 ffff88012bc31e88 0000000000000000 ffff88012111f878 ffff88012bc31c00
 ffffffff81383030 0000000000000040 0000000000010140 ffff88012ba409d8
 ffff88012111f8a8 ffffffff810df975 ffffffff810e4c69 ffff88012bc31c00
Call Trace:
 [<ffffffff810df975>] shrink_dcache_for_umount+0x37/0x47
 [<ffffffff810e4c69>] ? free_vfsmnt+0x50/0x55
 [<ffffffff810d209d>] generic_shutdown_super+0x1e/0xea
 [<ffffffff810d21b4>] kill_anon_super+0x11/0x43
 [<ffffffff810d2208>] kill_litter_super+0x22/0x26
 [<ffffffff810d2840>] deactivate_super+0x6a/0x82
 [<ffffffff810e4d7b>] mntput_no_expire+0x10d/0x14e
 [<ffffffff810d8d53>] ? path_walk+0xc7/0xd4
 [<ffffffff810d7793>] mntput+0x18/0x1a
 [<ffffffff810d78b4>] path_put+0x1d/0x22
 [<ffffffff8121d2c0>] devtmpfs_create_node+0x209/0x229
 [<ffffffff810e11a2>] ? iput+0x2f/0x66
 [<ffffffff81120f90>] ? sysfs_addrm_finish+0x69/0x217
 [<ffffffff81120bd1>] ? sysfs_add_one+0x1c/0xe6
 [<ffffffff81121a63>] ? sysfs_do_create_link+0xe0/0x131
 [<ffffffff81217c6a>] device_add+0x1a7/0x54b
 [<ffffffff81183ff4>] ? kobject_init+0x43/0x83
 [<ffffffff81218027>] device_register+0x19/0x1d
 [<ffffffff812180c3>] device_create_vargs+0x98/0xc6
 [<ffffffff8121811d>] device_create+0x2c/0x2e
 [<ffffffff811ff222>] ? reset_terminal+0x2d0/0x2d5
 [<ffffffff811fa673>] vcs_make_sysfs+0x33/0x62
 [<ffffffff81200949>] vc_allocate+0x186/0x1aa
 [<ffffffff8105defc>] ? down+0x33/0x3b
 [<ffffffff8120099f>] con_open+0x32/0xc2
 [<ffffffff811f2c4f>] tty_open+0x2ef/0x430
 [<ffffffff810d2c52>] chrdev_open+0x14b/0x16a
 [<ffffffff811579c4>] ? selinux_dentry_open+0xed/0xf6
 [<ffffffff810d2b07>] ? chrdev_open+0x0/0x16a
 [<ffffffff810ce576>] __dentry_open+0x150/0x269
 [<ffffffff810ce75c>] nameidata_to_filp+0x41/0x53
 [<ffffffff810da1ff>] do_filp_open+0x494/0x8b2
 [<ffffffff810e4c9f>] ? mntput_no_expire+0x31/0x14e
 [<ffffffff8118a755>] ? might_fault+0x1a/0x1c
 [<ffffffff810e3540>] ? alloc_fd+0x110/0x124
 [<ffffffff810ce369>] do_sys_open+0x56/0xd6
 [<ffffffff810ce412>] sys_open+0x1b/0x1d
 [<ffffffff81010c02>] system_call_fastpath+0x16/0x1b
Code: 08 49 8b 44 24 10 48 85 c0 74 04 48 8b 50 40 48 8d 86 88 02 00 00 48 c7 c7 0e cb 48 81 4c 89 e6 48 89 04 24 31 c0 e8 79 8f 28 00 <0f> 0b eb fe 49 8b 5c 24 28 49 39 dc 75 04 31 db eb 03 f0 ff 0b 
RIP  [<ffffffff810df875>] shrink_dcache_for_umount_subtree+0x1ac/0x275
 RSP <ffff88012111f848>
---[ end trace 5ce2844beb187c5b ]---

[-- Attachment #2: config --]
[-- Type: text/plain, Size: 91978 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.30-rc5
# Mon May 11 11:11:00 2009
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_FAST_CMPXCHG_LOCAL=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_HAVE_DYNAMIC_PER_CPU_AREA=y
CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_TRAMPOLINE=y
# CONFIG_KTIME_SCALAR is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_TREE=y

#
# RCU Subsystem
#
CONFIG_CLASSIC_RCU=y
# CONFIG_TREE_RCU is not set
# CONFIG_PREEMPT_RCU is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_PREEMPT_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_RT_GROUP_SCHED=y
# CONFIG_USER_SCHED is not set
CONFIG_CGROUP_SCHED=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_NS=y
# CONFIG_CGROUP_FREEZER is not set
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_CGROUP_MEM_RES_CTLR is not set
# CONFIG_SYSFS_DEPRECATED_V2 is not set
CONFIG_RELAY=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
# CONFIG_NET_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_MARKERS=y
CONFIG_OPROFILE=m
# CONFIG_OPROFILE_IBS is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_API_DEBUG=y
# CONFIG_SLOW_WORK is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_INTEGRITY=y
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
# CONFIG_SPARSE_IRQ is not set
CONFIG_X86_MPPARSE=y
CONFIG_X86_EXTENDED_PLATFORM=y
# CONFIG_X86_VSMP is not set
# CONFIG_X86_UV is not set
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_PARAVIRT_GUEST=y
CONFIG_XEN=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=32
CONFIG_XEN_SAVE_RESTORE=y
# CONFIG_XEN_DEBUG_FS is not set
CONFIG_KVM_CLOCK=y
CONFIG_KVM_GUEST=y
CONFIG_PARAVIRT=y
CONFIG_PARAVIRT_CLOCK=y
# CONFIG_PARAVIRT_DEBUG is not set
# CONFIG_MEMTEST is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_CPU=y
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
# CONFIG_X86_DS is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
CONFIG_CALGARY_IOMMU=y
CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y
CONFIG_AMD_IOMMU=y
# CONFIG_AMD_IOMMU_STATS is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
CONFIG_IOMMU_API=y
# CONFIG_MAXSMP is not set
CONFIG_NR_CPUS=64
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_AMD=y
CONFIG_X86_MCE_THRESHOLD=y
CONFIG_I8K=m
CONFIG_MICROCODE=m
CONFIG_MICROCODE_INTEL=y
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
# CONFIG_X86_CPU_DEBUG is not set
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_DIRECT_GBPAGES=y
CONFIG_NUMA=y
CONFIG_K8_NUMA=y
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_NODES_SPAN_OTHER_NODES=y
# CONFIG_NUMA_EMU is not set
CONFIG_NODES_SHIFT=9
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_NEED_MULTIPLE_NODES=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_VMEMMAP=y

#
# Memory hotplug is currently incompatible with Software Suspend
#
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_UNEVICTABLE_LRU=y
CONFIG_HAVE_MLOCK=y
CONFIG_HAVE_MLOCKED_PAGE_BIT=y
CONFIG_MMU_NOTIFIER=y
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_X86_RESERVE_LOW_64K=y
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_EFI=y
CONFIG_SECCOMP=y
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
# CONFIG_KEXEC_JUMP is not set
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
CONFIG_PHYSICAL_ALIGN=0x200000
CONFIG_HOTPLUG_CPU=y
# CONFIG_COMPAT_VDSO is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y

#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_VERBOSE is not set
CONFIG_CAN_PM_TRACE=y
CONFIG_PM_TRACE=y
CONFIG_PM_TRACE_RTC=y
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
# CONFIG_PM_TEST_SUSPEND is not set
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_NUMA=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_PCI_SLOT=m
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
CONFIG_ACPI_SBS=m

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=m
CONFIG_CPU_FREQ_DEBUG=y
CONFIG_CPU_FREQ_STAT=m
CONFIG_CPU_FREQ_STAT_DETAILS=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=m
CONFIG_X86_POWERNOW_K8=m
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
CONFIG_X86_P4_CLOCKMOD=m

#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=m
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y

#
# Memory power savings
#
# CONFIG_I7300_IDLE is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
# CONFIG_DMAR is not set
# CONFIG_INTR_REMAP is not set
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=m
CONFIG_PCIEAER=y
CONFIG_PCIEASPM=y
# CONFIG_PCIEASPM_DEBUG is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
CONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_STUB is not set
CONFIG_HT_IRQ=y
# CONFIG_PCI_IOV is not set
CONFIG_ISA_DMA_API=y
CONFIG_K8_NB=y
CONFIG_PCCARD=y
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=m
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
CONFIG_PD6729=m
CONFIG_I82092=m
CONFIG_PCCARD_NONSTATIC=m
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_FAKE=m
CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_HOTPLUG_PCI_ACPI_IBM=m
# CONFIG_HOTPLUG_PCI_CPCI is not set
CONFIG_HOTPLUG_PCI_SHPC=m

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_XFRM_SUB_POLICY=y
CONFIG_XFRM_MIGRATE=y
CONFIG_XFRM_STATISTICS=y
CONFIG_XFRM_IPCOMP=m
CONFIG_NET_KEY=m
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=m
CONFIG_TCP_CONG_CUBIC=y
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=m
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
CONFIG_TCP_CONG_YEAH=m
CONFIG_TCP_CONG_ILLINOIS=m
# CONFIG_DEFAULT_BIC is not set
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CONFIG_DEFAULT_WESTWOOD is not set
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_IPV6_OPTIMISTIC_DAD=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_MIP6=m
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
CONFIG_IPV6_SIT=m
CONFIG_IPV6_NDISC_NODETYPE=y
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_IPV6_SUBTREES=y
CONFIG_IPV6_MROUTE=y
CONFIG_IPV6_PIMSM_V2=y
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=y

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NF_CONNTRACK=y
CONFIG_NF_CT_ACCT=y
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CT_PROTO_DCCP=m
CONFIG_NF_CT_PROTO_GRE=m
CONFIG_NF_CT_PROTO_SCTP=m
CONFIG_NF_CT_PROTO_UDPLITE=m
CONFIG_NF_CONNTRACK_AMANDA=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_H323=m
CONFIG_NF_CONNTRACK_IRC=m
CONFIG_NF_CONNTRACK_NETBIOS_NS=m
CONFIG_NF_CONNTRACK_PPTP=m
CONFIG_NF_CONNTRACK_SANE=m
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NF_CONNTRACK_TFTP=m
CONFIG_NF_CT_NETLINK=m
# CONFIG_NETFILTER_TPROXY is not set
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_HL=m
# CONFIG_NETFILTER_XT_TARGET_LED is not set
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_RATEEST=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
# CONFIG_NETFILTER_XT_MATCH_CLUSTER is not set
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
CONFIG_NETFILTER_XT_MATCH_DCCP=m
CONFIG_NETFILTER_XT_MATCH_DSCP=m
CONFIG_NETFILTER_XT_MATCH_ESP=m
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_HL=m
CONFIG_NETFILTER_XT_MATCH_IPRANGE=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_OWNER=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_QUOTA=m
CONFIG_NETFILTER_XT_MATCH_RATEEST=m
CONFIG_NETFILTER_XT_MATCH_REALM=m
# CONFIG_NETFILTER_XT_MATCH_RECENT is not set
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_STATE=y
CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_TIME=m
CONFIG_NETFILTER_XT_MATCH_U32=m
CONFIG_IP_VS=m
# CONFIG_IP_VS_IPV6 is not set
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12

#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_AH_ESP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y

#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m

#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m

#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=y
CONFIG_NF_CONNTRACK_IPV4=y
# CONFIG_NF_CONNTRACK_PROC_COMPAT is not set
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_NF_NAT_PROTO_DCCP=m
CONFIG_NF_NAT_PROTO_GRE=m
CONFIG_NF_NAT_PROTO_UDPLITE=m
CONFIG_NF_NAT_PROTO_SCTP=m
CONFIG_NF_NAT_FTP=m
CONFIG_NF_NAT_IRC=m
CONFIG_NF_NAT_TFTP=m
CONFIG_NF_NAT_AMANDA=m
CONFIG_NF_NAT_PPTP=m
CONFIG_NF_NAT_H323=m
CONFIG_NF_NAT_SIP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_SECURITY=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m

#
# IPv6: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV6=m
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_AH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_MH=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_TARGET_HL=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_RAW=m
CONFIG_IP6_NF_SECURITY=m

#
# DECnet: Netfilter Configuration
#
# CONFIG_DECNET_NF_GRABULATOR is not set
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
CONFIG_BRIDGE_EBT_IP6=m
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
CONFIG_BRIDGE_EBT_ULOG=m
CONFIG_BRIDGE_EBT_NFLOG=m
CONFIG_IP_DCCP=m
CONFIG_INET_DCCP_DIAG=m

#
# DCCP CCIDs Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP_CCID2_DEBUG is not set
CONFIG_IP_DCCP_CCID3=y
# CONFIG_IP_DCCP_CCID3_DEBUG is not set
CONFIG_IP_DCCP_CCID3_RTO=100
CONFIG_IP_DCCP_TFRC_LIB=y

#
# DCCP Kernel Hacking
#
# CONFIG_IP_DCCP_DEBUG is not set
CONFIG_NET_DCCPPROBE=m
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
# CONFIG_RDS is not set
CONFIG_TIPC=m
# CONFIG_TIPC_ADVANCED is not set
# CONFIG_TIPC_DEBUG is not set
CONFIG_ATM=m
CONFIG_ATM_CLIP=m
# CONFIG_ATM_CLIP_NO_ICMP is not set
CONFIG_ATM_LANE=m
# CONFIG_ATM_MPOA is not set
CONFIG_ATM_BR2684=m
# CONFIG_ATM_BR2684_IPFILTER is not set
CONFIG_STP=m
CONFIG_GARP=m
CONFIG_BRIDGE=m
# CONFIG_NET_DSA is not set
CONFIG_VLAN_8021Q=m
CONFIG_VLAN_8021Q_GVRP=y
CONFIG_DECNET=m
CONFIG_DECNET_ROUTER=y
CONFIG_LLC=y
# CONFIG_LLC2 is not set
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
CONFIG_ATALK=m
CONFIG_DEV_APPLETALK=m
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
CONFIG_WAN_ROUTER=m
# CONFIG_PHONET is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_ATM=m
CONFIG_NET_SCH_PRIO=m
# CONFIG_NET_SCH_MULTIQ is not set
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
# CONFIG_NET_SCH_DRR is not set
CONFIG_NET_SCH_INGRESS=m

#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_FLOW=m
# CONFIG_NET_CLS_CGROUP is not set
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=m
CONFIG_NET_EMATCH_NBYTE=m
CONFIG_NET_EMATCH_U32=m
CONFIG_NET_EMATCH_META=m
CONFIG_NET_EMATCH_TEXT=m
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=m
CONFIG_NET_ACT_GACT=m
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=m
CONFIG_NET_ACT_IPT=m
CONFIG_NET_ACT_NAT=m
CONFIG_NET_ACT_PEDIT=m
CONFIG_NET_ACT_SIMP=m
# CONFIG_NET_ACT_SKBEDIT is not set
CONFIG_NET_CLS_IND=y
CONFIG_NET_SCH_FIFO=y
# CONFIG_DCB is not set

#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_NET_TCPPROBE is not set
# CONFIG_NET_DROP_MONITOR is not set
CONFIG_HAMRADIO=y

#
# Packet Radio protocols
#
CONFIG_AX25=m
CONFIG_AX25_DAMA_SLAVE=y
CONFIG_NETROM=m
CONFIG_ROSE=m

#
# AX.25 network device drivers
#
CONFIG_MKISS=m
CONFIG_6PACK=m
CONFIG_BPQETHER=m
CONFIG_BAYCOM_SER_FDX=m
CONFIG_BAYCOM_SER_HDX=m
CONFIG_BAYCOM_PAR=m
CONFIG_YAM=m
CONFIG_CAN=m
CONFIG_CAN_RAW=m
CONFIG_CAN_BCM=m

#
# CAN Device Drivers
#
CONFIG_CAN_VCAN=m
# CONFIG_CAN_DEBUG_DEVICES is not set
CONFIG_IRDA=m

#
# IrDA protocols
#
CONFIG_IRLAN=m
CONFIG_IRNET=m
CONFIG_IRCOMM=m
# CONFIG_IRDA_ULTRA is not set

#
# IrDA options
#
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRDA_FAST_RR=y
# CONFIG_IRDA_DEBUG is not set

#
# Infrared-port device drivers
#

#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m

#
# Dongle support
#
CONFIG_DONGLE=y
CONFIG_ESI_DONGLE=m
CONFIG_ACTISYS_DONGLE=m
CONFIG_TEKRAM_DONGLE=m
CONFIG_TOIM3232_DONGLE=m
CONFIG_LITELINK_DONGLE=m
CONFIG_MA600_DONGLE=m
CONFIG_GIRBIL_DONGLE=m
CONFIG_MCP2120_DONGLE=m
CONFIG_OLD_BELKIN_DONGLE=m
CONFIG_ACT200L_DONGLE=m
CONFIG_KINGSUN_DONGLE=m
CONFIG_KSDAZZLE_DONGLE=m
CONFIG_KS959_DONGLE=m

#
# FIR device drivers
#
CONFIG_USB_IRDA=m
CONFIG_SIGMATEL_FIR=m
CONFIG_NSC_FIR=m
CONFIG_WINBOND_FIR=m
CONFIG_SMC_IRCC_FIR=m
CONFIG_ALI_FIR=m
CONFIG_VLSI_FIR=m
CONFIG_VIA_FIR=m
CONFIG_MCS_FIR=m
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_CMTP=m
CONFIG_BT_HIDP=m

#
# Bluetooth device drivers
#
CONFIG_BT_HCIBTUSB=m
CONFIG_BT_HCIBTSDIO=m
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_LL=y
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIDTL1=m
CONFIG_BT_HCIBT3C=m
CONFIG_BT_HCIBLUECARD=m
CONFIG_BT_HCIBTUART=m
CONFIG_BT_HCIVHCI=m
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y
# CONFIG_WIRELESS is not set
CONFIG_WIRELESS_EXT=y
CONFIG_LIB80211=m
CONFIG_LIB80211_CRYPT_WEP=m
CONFIG_LIB80211_CRYPT_CCMP=m
CONFIG_LIB80211_CRYPT_TKIP=m
# CONFIG_WIMAX is not set
CONFIG_RFKILL=m
CONFIG_RFKILL_INPUT=m
CONFIG_RFKILL_LEDS=y
CONFIG_NET_9P=m
CONFIG_NET_9P_VIRTIO=m
# CONFIG_NET_9P_RDMA is not set
# CONFIG_NET_9P_DEBUG is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
CONFIG_DEBUG_DEVRES=y
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_MTD=m
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_CONCAT=m
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_TESTS is not set
CONFIG_MTD_REDBOOT_PARTS=m
CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1
# CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set
# CONFIG_MTD_REDBOOT_PARTS_READONLY is not set
CONFIG_MTD_AR7_PARTS=m

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=m
CONFIG_MTD_BLKDEVS=m
CONFIG_MTD_BLOCK=m
CONFIG_MTD_BLOCK_RO=m
CONFIG_FTL=m
CONFIG_NFTL=m
CONFIG_NFTL_RW=y
CONFIG_INFTL=m
CONFIG_RFD_FTL=m
CONFIG_SSFDC=m
CONFIG_MTD_OOPS=m

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=m
CONFIG_MTD_JEDECPROBE=m
CONFIG_MTD_GEN_PROBE=m
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=m
CONFIG_MTD_CFI_AMDSTD=m
CONFIG_MTD_CFI_STAA=m
CONFIG_MTD_CFI_UTIL=m
CONFIG_MTD_RAM=m
CONFIG_MTD_ROM=m
CONFIG_MTD_ABSENT=m

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
# CONFIG_MTD_PHYSMAP is not set
CONFIG_MTD_SC520CDP=m
CONFIG_MTD_NETSC520=m
CONFIG_MTD_TS5500=m
# CONFIG_MTD_SBC_GXX is not set
# CONFIG_MTD_AMD76XROM is not set
# CONFIG_MTD_ICHXROM is not set
CONFIG_MTD_ESB2ROM=m
CONFIG_MTD_CK804XROM=m
CONFIG_MTD_SCB2_FLASH=m
# CONFIG_MTD_NETtel is not set
# CONFIG_MTD_DILNETPC is not set
# CONFIG_MTD_L440GX is not set
CONFIG_MTD_PCI=m
# CONFIG_MTD_INTEL_VR_NOR is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
CONFIG_MTD_PMC551=m
# CONFIG_MTD_PMC551_BUGFIX is not set
# CONFIG_MTD_PMC551_DEBUG is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
CONFIG_MTD_MTDRAM=m
CONFIG_MTDRAM_TOTAL_SIZE=4096
CONFIG_MTDRAM_ERASE_SIZE=128
CONFIG_MTD_BLOCK2MTD=m

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
CONFIG_MTD_NAND=m
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
CONFIG_MTD_NAND_ECC_SMC=y
# CONFIG_MTD_NAND_MUSEUM_IDS is not set
CONFIG_MTD_NAND_IDS=m
CONFIG_MTD_NAND_DISKONCHIP=m
# CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED is not set
CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0
# CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE is not set
# CONFIG_MTD_NAND_CAFE is not set
CONFIG_MTD_NAND_NANDSIM=m
# CONFIG_MTD_NAND_PLATFORM is not set
CONFIG_MTD_ALAUDA=m
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set

#
# UBI - Unsorted block images
#
CONFIG_MTD_UBI=m
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
# CONFIG_MTD_UBI_GLUEBI is not set

#
# UBI debugging options
#
# CONFIG_MTD_UBI_DEBUG is not set
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_SERIAL=m
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
CONFIG_PARPORT_PC_PCMCIA=m
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y
CONFIG_PARPORT_NOT_PC=y
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=m
CONFIG_PARIDE=m

#
# Parallel IDE high-level drivers
#
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m

#
# Parallel IDE protocol modules
#
CONFIG_PARIDE_ATEN=m
CONFIG_PARIDE_BPCK=m
CONFIG_PARIDE_COMM=m
CONFIG_PARIDE_DSTR=m
CONFIG_PARIDE_FIT2=m
CONFIG_PARIDE_FIT3=m
CONFIG_PARIDE_EPAT=m
CONFIG_PARIDE_EPATC8=y
CONFIG_PARIDE_EPIA=m
CONFIG_PARIDE_FRIQ=m
CONFIG_PARIDE_FRPW=m
CONFIG_PARIDE_KBIC=m
CONFIG_PARIDE_KTTI=m
CONFIG_PARIDE_ON20=m
CONFIG_PARIDE_ON26=m
CONFIG_BLK_CPQ_DA=m
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_CISS_SCSI_TAPE=y
CONFIG_BLK_DEV_DAC960=m
CONFIG_BLK_DEV_UMEM=m
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_SX8=m
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
CONFIG_ATA_OVER_ETH=m
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_VIRTIO_BLK=m
# CONFIG_BLK_DEV_HD is not set
CONFIG_MISC_DEVICES=y
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
CONFIG_SGI_IOC4=m
CONFIG_TIFM_CORE=m
CONFIG_TIFM_7XX1=m
# CONFIG_ICS932S401 is not set
CONFIG_ENCLOSURE_SERVICES=m
# CONFIG_HP_ILO is not set
# CONFIG_DELL_LAPTOP is not set
# CONFIG_ISL29003 is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_LEGACY is not set
CONFIG_EEPROM_93CX6=m
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_TGT=m
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
CONFIG_CHR_DEV_SCH=m
CONFIG_SCSI_ENCLOSURE=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_FC_TGT_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
CONFIG_SCSI_SAS_ATA=y
CONFIG_SCSI_SAS_HOST_SMP=y
# CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set
CONFIG_SCSI_SRP_ATTRS=m
CONFIG_SCSI_SRP_TGT_ATTRS=y
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_TCP=m
# CONFIG_SCSI_CXGB3_ISCSI is not set
CONFIG_BLK_DEV_3W_XXXX_RAID=m
CONFIG_SCSI_3W_9XXX=m
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AACRAID=m
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=4
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
CONFIG_SCSI_AIC7XXX_OLD=m
CONFIG_SCSI_AIC79XX=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=4
CONFIG_AIC79XX_RESET_DELAY_MS=15000
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
CONFIG_SCSI_AIC94XX=m
# CONFIG_AIC94XX_DEBUG is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
CONFIG_SCSI_ARCMSR=m
CONFIG_SCSI_ARCMSR_AER=y
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=m
CONFIG_MEGARAID_MAILBOX=m
CONFIG_MEGARAID_LEGACY=m
CONFIG_MEGARAID_SAS=m
# CONFIG_SCSI_MPT2SAS is not set
CONFIG_SCSI_HPTIOP=m
CONFIG_SCSI_BUSLOGIC=m
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_FCOE is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
CONFIG_SCSI_GDTH=m
CONFIG_SCSI_IPS=m
CONFIG_SCSI_INITIO=m
CONFIG_SCSI_INIA100=m
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
# CONFIG_SCSI_IZIP_EPP16 is not set
# CONFIG_SCSI_IZIP_SLOW_CTR is not set
CONFIG_SCSI_MVSAS=m
CONFIG_SCSI_STEX=m
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
CONFIG_SCSI_SYM53C8XX_MMIO=y
# CONFIG_SCSI_IPR is not set
CONFIG_SCSI_QLOGIC_1280=m
CONFIG_SCSI_QLA_FC=m
CONFIG_SCSI_QLA_ISCSI=m
CONFIG_SCSI_LPFC=m
# CONFIG_SCSI_LPFC_DEBUG_FS is not set
CONFIG_SCSI_DC395x=m
CONFIG_SCSI_DC390T=m
# CONFIG_SCSI_DEBUG is not set
CONFIG_SCSI_SRP=m
CONFIG_SCSI_LOWLEVEL_PCMCIA=y
# CONFIG_PCMCIA_FDOMAIN is not set
CONFIG_PCMCIA_QLOGIC=m
CONFIG_PCMCIA_SYM53C500=m
CONFIG_SCSI_DH=y
CONFIG_SCSI_DH_RDAC=m
CONFIG_SCSI_DH_HP_SW=m
CONFIG_SCSI_DH_EMC=m
CONFIG_SCSI_DH_ALUA=m
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
CONFIG_SATA_PMP=y
CONFIG_SATA_AHCI=y
CONFIG_SATA_SIL24=m
CONFIG_ATA_SFF=y
CONFIG_SATA_SVW=m
CONFIG_ATA_PIIX=y
CONFIG_SATA_MV=m
CONFIG_SATA_NV=m
CONFIG_PDC_ADMA=m
CONFIG_SATA_QSTOR=m
CONFIG_SATA_PROMISE=m
CONFIG_SATA_SX4=m
CONFIG_SATA_SIL=m
CONFIG_SATA_SIS=m
CONFIG_SATA_ULI=m
CONFIG_SATA_VIA=m
CONFIG_SATA_VITESSE=m
CONFIG_SATA_INIC162X=m
CONFIG_PATA_ACPI=m
CONFIG_PATA_ALI=m
CONFIG_PATA_AMD=m
CONFIG_PATA_ARTOP=m
CONFIG_PATA_ATIIXP=m
CONFIG_PATA_CMD640_PCI=m
CONFIG_PATA_CMD64X=m
CONFIG_PATA_CS5520=m
CONFIG_PATA_CS5530=m
CONFIG_PATA_CYPRESS=m
CONFIG_PATA_EFAR=m
CONFIG_ATA_GENERIC=m
CONFIG_PATA_HPT366=m
CONFIG_PATA_HPT37X=m
CONFIG_PATA_HPT3X2N=m
CONFIG_PATA_HPT3X3=m
# CONFIG_PATA_HPT3X3_DMA is not set
CONFIG_PATA_IT821X=m
CONFIG_PATA_IT8213=m
CONFIG_PATA_JMICRON=m
CONFIG_PATA_TRIFLEX=m
CONFIG_PATA_MARVELL=m
CONFIG_PATA_MPIIX=m
CONFIG_PATA_OLDPIIX=m
CONFIG_PATA_NETCELL=m
CONFIG_PATA_NINJA32=m
CONFIG_PATA_NS87410=m
CONFIG_PATA_NS87415=m
CONFIG_PATA_OPTI=m
CONFIG_PATA_OPTIDMA=m
CONFIG_PATA_PCMCIA=m
CONFIG_PATA_PDC_OLD=m
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
CONFIG_PATA_SERVERWORKS=m
CONFIG_PATA_PDC2027X=m
CONFIG_PATA_SIL680=m
CONFIG_PATA_SIS=m
CONFIG_PATA_VIA=m
CONFIG_PATA_WINBOND=m
CONFIG_PATA_SCH=m
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_AUTODETECT=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
CONFIG_MD_RAID6_PQ=m
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
CONFIG_BLK_DEV_DM=y
CONFIG_DM_DEBUG=y
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=y
CONFIG_DM_MIRROR=y
CONFIG_DM_ZERO=y
CONFIG_DM_MULTIPATH=m
# CONFIG_DM_DELAY is not set
CONFIG_DM_UEVENT=y
CONFIG_FUSION=y
CONFIG_FUSION_SPI=m
CONFIG_FUSION_FC=m
CONFIG_FUSION_SAS=m
CONFIG_FUSION_MAX_SGE=40
CONFIG_FUSION_CTL=m
CONFIG_FUSION_LAN=m
CONFIG_FUSION_LOGGING=y

#
# IEEE 1394 (FireWire) support
#

#
# Enable only one of the two stacks, unless you know what you are doing
#
CONFIG_FIREWIRE=m
CONFIG_FIREWIRE_OHCI=m
CONFIG_FIREWIRE_OHCI_DEBUG=y
CONFIG_FIREWIRE_SBP2=m
# CONFIG_IEEE1394 is not set
CONFIG_I2O=m
# CONFIG_I2O_LCT_NOTIFY_ON_CHANGES is not set
CONFIG_I2O_EXT_ADAPTEC=y
CONFIG_I2O_EXT_ADAPTEC_DMA64=y
CONFIG_I2O_CONFIG=m
CONFIG_I2O_CONFIG_OLD_IOCTL=y
CONFIG_I2O_BUS=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_MAC_EMUMOUSEBTN=y
CONFIG_NETDEVICES=y
CONFIG_COMPAT_NET_DEV_OPS=y
CONFIG_IFB=m
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_MACVLAN=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
CONFIG_VETH=m
CONFIG_NET_SB1000=m
# CONFIG_ARCNET is not set
CONFIG_PHYLIB=m

#
# MII PHY device drivers
#
CONFIG_MARVELL_PHY=m
CONFIG_DAVICOM_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_LXT_PHY=m
CONFIG_CICADA_PHY=m
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
CONFIG_BROADCOM_PHY=m
CONFIG_ICPLUS_PHY=m
CONFIG_REALTEK_PHY=m
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
CONFIG_MDIO_BITBANG=m
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_CASSINI=m
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=m
CONFIG_TYPHOON=m
# CONFIG_ETHOC is not set
# CONFIG_DNET is not set
CONFIG_NET_TULIP=y
CONFIG_DE2104X=m
CONFIG_TULIP=m
# CONFIG_TULIP_MWI is not set
CONFIG_TULIP_MMIO=y
# CONFIG_TULIP_NAPI is not set
CONFIG_DE4X5=m
CONFIG_WINBOND_840=m
CONFIG_DM9102=m
CONFIG_ULI526X=m
CONFIG_PCMCIA_XIRCOM=m
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
CONFIG_AMD8111_ETH=m
CONFIG_ADAPTEC_STARFIRE=m
CONFIG_B44=m
CONFIG_B44_PCI_AUTOSELECT=y
CONFIG_B44_PCICORE_AUTOSELECT=y
CONFIG_B44_PCI=y
CONFIG_FORCEDETH=m
CONFIG_FORCEDETH_NAPI=y
CONFIG_E100=m
CONFIG_FEALNX=m
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=m
CONFIG_8139CP=m
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_R6040=m
CONFIG_SIS900=m
CONFIG_EPIC100=m
# CONFIG_SMSC9420 is not set
CONFIG_SUNDANCE=m
# CONFIG_SUNDANCE_MMIO is not set
CONFIG_TLAN=m
CONFIG_VIA_RHINE=m
CONFIG_VIA_RHINE_MMIO=y
CONFIG_SC92031=m
CONFIG_NET_POCKET=y
CONFIG_ATP=m
CONFIG_DE600=m
CONFIG_DE620=m
CONFIG_ATL2=m
CONFIG_NETDEV_1000=y
CONFIG_ACENIC=m
# CONFIG_ACENIC_OMIT_TIGON_I is not set
CONFIG_DL2K=m
CONFIG_E1000=m
CONFIG_E1000E=m
CONFIG_IP1000=m
CONFIG_IGB=m
CONFIG_IGB_DCA=y
# CONFIG_IGBVF is not set
CONFIG_NS83820=m
CONFIG_HAMACHI=m
CONFIG_YELLOWFIN=m
CONFIG_R8169=m
CONFIG_R8169_VLAN=y
CONFIG_SIS190=m
CONFIG_SKGE=m
# CONFIG_SKGE_DEBUG is not set
CONFIG_SKY2=m
# CONFIG_SKY2_DEBUG is not set
CONFIG_VIA_VELOCITY=m
CONFIG_TIGON3=m
CONFIG_BNX2=m
CONFIG_QLA3XXX=m
CONFIG_ATL1=m
CONFIG_ATL1E=m
# CONFIG_ATL1C is not set
# CONFIG_JME is not set
CONFIG_NETDEV_10000=y
CONFIG_CHELSIO_T1=m
CONFIG_CHELSIO_T1_1G=y
CONFIG_CHELSIO_T3_DEPENDS=y
CONFIG_CHELSIO_T3=m
# CONFIG_ENIC is not set
CONFIG_IXGBE=m
CONFIG_IXGBE_DCA=y
CONFIG_IXGB=m
CONFIG_S2IO=m
# CONFIG_VXGE is not set
CONFIG_MYRI10GE=m
CONFIG_MYRI10GE_DCA=y
CONFIG_NETXEN_NIC=m
CONFIG_NIU=m
# CONFIG_MLX4_EN is not set
CONFIG_MLX4_CORE=m
CONFIG_MLX4_DEBUG=y
CONFIG_TEHUTI=m
CONFIG_BNX2X=m
# CONFIG_QLGE is not set
# CONFIG_SFC is not set
# CONFIG_BE2NET is not set
CONFIG_TR=y
CONFIG_IBMOL=m
CONFIG_3C359=m
# CONFIG_TMS380TR is not set

#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
CONFIG_WLAN_80211=y
# CONFIG_PCMCIA_RAYCS is not set
CONFIG_LIBERTAS=m
CONFIG_LIBERTAS_USB=m
CONFIG_LIBERTAS_CS=m
CONFIG_LIBERTAS_SDIO=m
CONFIG_LIBERTAS_DEBUG=y
CONFIG_AIRO=m
CONFIG_ATMEL=m
CONFIG_PCI_ATMEL=m
CONFIG_PCMCIA_ATMEL=m
CONFIG_AIRO_CS=m
CONFIG_PCMCIA_WL3501=m
CONFIG_PRISM54=m
CONFIG_USB_ZD1201=m
CONFIG_USB_NET_RNDIS_WLAN=m
CONFIG_IPW2100=m
CONFIG_IPW2100_MONITOR=y
# CONFIG_IPW2100_DEBUG is not set
CONFIG_IPW2200=m
CONFIG_IPW2200_MONITOR=y
CONFIG_IPW2200_RADIOTAP=y
CONFIG_IPW2200_PROMISCUOUS=y
CONFIG_IPW2200_QOS=y
# CONFIG_IPW2200_DEBUG is not set
CONFIG_LIBIPW=m
# CONFIG_LIBIPW_DEBUG is not set
CONFIG_HOSTAP=m
CONFIG_HOSTAP_FIRMWARE=y
CONFIG_HOSTAP_FIRMWARE_NVRAM=y
CONFIG_HOSTAP_PLX=m
CONFIG_HOSTAP_PCI=m
CONFIG_HOSTAP_CS=m
CONFIG_HERMES=m
CONFIG_HERMES_CACHE_FW_ON_INIT=y
CONFIG_PLX_HERMES=m
CONFIG_TMD_HERMES=m
CONFIG_NORTEL_HERMES=m
CONFIG_PCI_HERMES=m
CONFIG_PCMCIA_HERMES=m
CONFIG_PCMCIA_SPECTRUM=m

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#

#
# USB Network Adapters
#
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET=m
CONFIG_USB_NET_AX8817X=m
CONFIG_USB_NET_CDCETHER=m
# CONFIG_USB_NET_CDC_EEM is not set
CONFIG_USB_NET_DM9601=m
# CONFIG_USB_NET_SMSC95XX is not set
CONFIG_USB_NET_GL620A=m
CONFIG_USB_NET_NET1080=m
CONFIG_USB_NET_PLUSB=m
CONFIG_USB_NET_MCS7830=m
CONFIG_USB_NET_RNDIS_HOST=m
CONFIG_USB_NET_CDC_SUBSET=m
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_KC2190=y
CONFIG_USB_NET_ZAURUS=m
CONFIG_USB_HSO=m
CONFIG_NET_PCMCIA=y
CONFIG_PCMCIA_3C589=m
CONFIG_PCMCIA_3C574=m
CONFIG_PCMCIA_FMVJ18X=m
CONFIG_PCMCIA_PCNET=m
CONFIG_PCMCIA_NMCLAN=m
CONFIG_PCMCIA_SMC91C92=m
CONFIG_PCMCIA_XIRC2PS=m
CONFIG_PCMCIA_AXNET=m
# CONFIG_PCMCIA_IBMTR is not set
# CONFIG_WAN is not set
CONFIG_ATM_DRIVERS=y
# CONFIG_ATM_DUMMY is not set
CONFIG_ATM_TCP=m
CONFIG_ATM_LANAI=m
CONFIG_ATM_ENI=m
# CONFIG_ATM_ENI_DEBUG is not set
# CONFIG_ATM_ENI_TUNE_BURST is not set
CONFIG_ATM_FIRESTREAM=m
# CONFIG_ATM_ZATM is not set
CONFIG_ATM_IDT77252=m
# CONFIG_ATM_IDT77252_DEBUG is not set
# CONFIG_ATM_IDT77252_RCV_ALL is not set
CONFIG_ATM_IDT77252_USE_SUNI=y
CONFIG_ATM_AMBASSADOR=m
# CONFIG_ATM_AMBASSADOR_DEBUG is not set
CONFIG_ATM_HORIZON=m
# CONFIG_ATM_HORIZON_DEBUG is not set
# CONFIG_ATM_IA is not set
CONFIG_ATM_FORE200E=m
# CONFIG_ATM_FORE200E_USE_TASKLET is not set
CONFIG_ATM_FORE200E_TX_RETRY=16
CONFIG_ATM_FORE200E_DEBUG=0
CONFIG_ATM_HE=m
# CONFIG_ATM_HE_USE_SUNI is not set
# CONFIG_ATM_SOLOS is not set
CONFIG_XEN_NETDEV_FRONTEND=m
CONFIG_FDDI=y
# CONFIG_DEFXX is not set
CONFIG_SKFP=m
# CONFIG_HIPPI is not set
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
# CONFIG_PPP_BSDCOMP is not set
CONFIG_PPP_MPPE=m
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
CONFIG_PPPOL2TP=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLHC=m
CONFIG_SLIP_SMART=y
# CONFIG_SLIP_MODE_SLIP6 is not set
CONFIG_NET_FC=y
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_NETPOLL=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_VIRTIO_NET=m
CONFIG_ISDN=y
CONFIG_MISDN=m
CONFIG_MISDN_DSP=m
CONFIG_MISDN_L1OIP=m

#
# mISDN hardware drivers
#
CONFIG_MISDN_HFCPCI=m
CONFIG_MISDN_HFCMULTI=m
# CONFIG_MISDN_HFCUSB is not set
CONFIG_ISDN_I4L=m
CONFIG_ISDN_PPP=y
CONFIG_ISDN_PPP_VJ=y
CONFIG_ISDN_MPP=y
CONFIG_IPPP_FILTER=y
# CONFIG_ISDN_PPP_BSDCOMP is not set
CONFIG_ISDN_AUDIO=y
CONFIG_ISDN_TTY_FAX=y

#
# ISDN feature submodules
#
CONFIG_ISDN_DIVERSION=m

#
# ISDN4Linux hardware drivers
#

#
# Passive cards
#
CONFIG_ISDN_DRV_HISAX=m

#
# D-channel protocol features
#
CONFIG_HISAX_EURO=y
CONFIG_DE_AOC=y
CONFIG_HISAX_NO_SENDCOMPLETE=y
CONFIG_HISAX_NO_LLC=y
CONFIG_HISAX_NO_KEYPAD=y
CONFIG_HISAX_1TR6=y
CONFIG_HISAX_NI1=y
CONFIG_HISAX_MAX_CARDS=8

#
# HiSax supported cards
#
CONFIG_HISAX_16_3=y
CONFIG_HISAX_TELESPCI=y
CONFIG_HISAX_S0BOX=y
CONFIG_HISAX_FRITZPCI=y
CONFIG_HISAX_AVM_A1_PCMCIA=y
CONFIG_HISAX_ELSA=y
CONFIG_HISAX_DIEHLDIVA=y
CONFIG_HISAX_SEDLBAUER=y
CONFIG_HISAX_NETJET=y
CONFIG_HISAX_NETJET_U=y
CONFIG_HISAX_NICCY=y
CONFIG_HISAX_BKM_A4T=y
CONFIG_HISAX_SCT_QUADRO=y
CONFIG_HISAX_GAZEL=y
CONFIG_HISAX_HFC_PCI=y
CONFIG_HISAX_W6692=y
CONFIG_HISAX_HFC_SX=y
CONFIG_HISAX_ENTERNOW_PCI=y
# CONFIG_HISAX_DEBUG is not set

#
# HiSax PCMCIA card service modules
#
CONFIG_HISAX_SEDLBAUER_CS=m
CONFIG_HISAX_ELSA_CS=m
CONFIG_HISAX_AVM_A1_CS=m
CONFIG_HISAX_TELES_CS=m

#
# HiSax sub driver modules
#
CONFIG_HISAX_ST5481=m
# CONFIG_HISAX_HFCUSB is not set
CONFIG_HISAX_HFC4S8S=m
CONFIG_HISAX_FRITZ_PCIPNP=m
CONFIG_HISAX_HDLC=y

#
# Active cards
#
CONFIG_HYSDN=m
CONFIG_HYSDN_CAPI=y
CONFIG_ISDN_DRV_GIGASET=m
CONFIG_GIGASET_BASE=m
CONFIG_GIGASET_M105=m
CONFIG_GIGASET_M101=m
# CONFIG_GIGASET_DEBUG is not set
# CONFIG_GIGASET_UNDOCREQ is not set
CONFIG_ISDN_CAPI=m
CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y
# CONFIG_CAPI_TRACE is not set
CONFIG_ISDN_CAPI_MIDDLEWARE=y
CONFIG_ISDN_CAPI_CAPI20=m
CONFIG_ISDN_CAPI_CAPIFS_BOOL=y
CONFIG_ISDN_CAPI_CAPIFS=m
CONFIG_ISDN_CAPI_CAPIDRV=m

#
# CAPI hardware drivers
#
CONFIG_CAPI_AVM=y
CONFIG_ISDN_DRV_AVMB1_B1PCI=m
CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y
CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m
CONFIG_ISDN_DRV_AVMB1_AVM_CS=m
CONFIG_ISDN_DRV_AVMB1_T1PCI=m
CONFIG_ISDN_DRV_AVMB1_C4=m
# CONFIG_CAPI_EICON is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y
CONFIG_INPUT_POLLDEV=m

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
CONFIG_XEN_KBDDEV_FRONTEND=y

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
CONFIG_MOUSE_SERIAL=m
CONFIG_MOUSE_APPLETOUCH=m
CONFIG_MOUSE_BCM5974=m
CONFIG_MOUSE_VSXXXAA=m
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
CONFIG_JOYSTICK_A3D=m
CONFIG_JOYSTICK_ADI=m
CONFIG_JOYSTICK_COBRA=m
CONFIG_JOYSTICK_GF2K=m
CONFIG_JOYSTICK_GRIP=m
CONFIG_JOYSTICK_GRIP_MP=m
CONFIG_JOYSTICK_GUILLEMOT=m
CONFIG_JOYSTICK_INTERACT=m
CONFIG_JOYSTICK_SIDEWINDER=m
CONFIG_JOYSTICK_TMDC=m
CONFIG_JOYSTICK_IFORCE=m
CONFIG_JOYSTICK_IFORCE_USB=y
CONFIG_JOYSTICK_IFORCE_232=y
CONFIG_JOYSTICK_WARRIOR=m
CONFIG_JOYSTICK_MAGELLAN=m
CONFIG_JOYSTICK_SPACEORB=m
CONFIG_JOYSTICK_SPACEBALL=m
CONFIG_JOYSTICK_STINGER=m
CONFIG_JOYSTICK_TWIDJOY=m
CONFIG_JOYSTICK_ZHENHUA=m
CONFIG_JOYSTICK_DB9=m
CONFIG_JOYSTICK_GAMECON=m
CONFIG_JOYSTICK_TURBOGRAFX=m
CONFIG_JOYSTICK_JOYDUMP=m
CONFIG_JOYSTICK_XPAD=m
CONFIG_JOYSTICK_XPAD_FF=y
CONFIG_JOYSTICK_XPAD_LEDS=y
# CONFIG_JOYSTICK_WALKERA0701 is not set
CONFIG_INPUT_TABLET=y
CONFIG_TABLET_USB_ACECAD=m
CONFIG_TABLET_USB_AIPTEK=m
CONFIG_TABLET_USB_GTCO=m
CONFIG_TABLET_USB_KBTAB=m
CONFIG_TABLET_USB_WACOM=m
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_AD7879_I2C is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
CONFIG_TOUCHSCREEN_FUJITSU=m
CONFIG_TOUCHSCREEN_GUNZE=m
CONFIG_TOUCHSCREEN_ELO=m
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
CONFIG_TOUCHSCREEN_MTOUCH=m
CONFIG_TOUCHSCREEN_INEXIO=m
CONFIG_TOUCHSCREEN_MK712=m
CONFIG_TOUCHSCREEN_PENMOUNT=m
CONFIG_TOUCHSCREEN_TOUCHRIGHT=m
CONFIG_TOUCHSCREEN_TOUCHWIN=m
# CONFIG_TOUCHSCREEN_WM97XX is not set
CONFIG_TOUCHSCREEN_USB_COMPOSITE=m
CONFIG_TOUCHSCREEN_USB_EGALAX=y
CONFIG_TOUCHSCREEN_USB_PANJIT=y
CONFIG_TOUCHSCREEN_USB_3M=y
CONFIG_TOUCHSCREEN_USB_ITM=y
CONFIG_TOUCHSCREEN_USB_ETURBO=y
CONFIG_TOUCHSCREEN_USB_GUNZE=y
CONFIG_TOUCHSCREEN_USB_DMC_TSC10=y
CONFIG_TOUCHSCREEN_USB_IRTOUCH=y
CONFIG_TOUCHSCREEN_USB_IDEALTEK=y
CONFIG_TOUCHSCREEN_USB_GENERAL_TOUCH=y
CONFIG_TOUCHSCREEN_USB_GOTOP=y
CONFIG_TOUCHSCREEN_TOUCHIT213=m
# CONFIG_TOUCHSCREEN_TSC2007 is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
CONFIG_INPUT_APANEL=m
CONFIG_INPUT_ATLAS_BTNS=m
CONFIG_INPUT_ATI_REMOTE=m
CONFIG_INPUT_ATI_REMOTE2=m
CONFIG_INPUT_KEYSPAN_REMOTE=m
CONFIG_INPUT_POWERMATE=m
CONFIG_INPUT_YEALINK=m
# CONFIG_INPUT_CM109 is not set
CONFIG_INPUT_UINPUT=m

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m
CONFIG_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
CONFIG_GAMEPORT_L4=m
CONFIG_GAMEPORT_EMU10K1=m
CONFIG_GAMEPORT_FM801=m

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_DEVKMEM is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
CONFIG_ROCKETPORT=m
CONFIG_CYCLADES=m
# CONFIG_CYZ_INTR is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
CONFIG_SYNCLINK=m
CONFIG_SYNCLINKMP=m
CONFIG_SYNCLINK_GT=m
CONFIG_N_HDLC=m
# CONFIG_RISCOM8 is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
# CONFIG_STALDRV is not set
CONFIG_NOZOMI=m

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_CONSOLE_POLL=y
CONFIG_SERIAL_JSM=m
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
CONFIG_LP_CONSOLE=y
CONFIG_PPDEV=m
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
CONFIG_VIRTIO_CONSOLE=m
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
CONFIG_HW_RANDOM_INTEL=m
CONFIG_HW_RANDOM_AMD=m
CONFIG_HW_RANDOM_VIRTIO=m
CONFIG_NVRAM=y
CONFIG_R3964=m
# CONFIG_APPLICOM is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
CONFIG_CARDMAN_4000=m
CONFIG_CARDMAN_4040=m
CONFIG_IPWIRELESS=m
CONFIG_MWAVE=m
# CONFIG_PC8736x_GPIO is not set
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=8192
CONFIG_HPET=y
# CONFIG_HPET_MMAP is not set
CONFIG_HANGCHECK_TIMER=m
CONFIG_TCG_TPM=m
CONFIG_TCG_TIS=m
CONFIG_TCG_NSC=m
CONFIG_TCG_ATMEL=m
CONFIG_TCG_INFINEON=m
CONFIG_TELCLOCK=m
CONFIG_DEVPORT=y
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD756_S4882=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_ISCH=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_NFORCE2_S4985=m
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
CONFIG_I2C_SIS96X=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_SIMTEC=m

#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_PARPORT=m
CONFIG_I2C_PARPORT_LIGHT=m
# CONFIG_I2C_TAOS_EVM is not set
CONFIG_I2C_TINY_USB=m

#
# Graphics adapter I2C/DDC channel drivers
#
CONFIG_I2C_VOODOO3=m

#
# Other I2C/SMBus bus drivers
#
CONFIG_I2C_PCA_PLATFORM=m
CONFIG_I2C_STUB=m

#
# Miscellaneous I2C Chip support
#
# CONFIG_DS1682 is not set
CONFIG_SENSORS_PCF8574=m
CONFIG_PCF8575=m
CONFIG_SENSORS_PCA9539=m
CONFIG_SENSORS_MAX6875=m
CONFIG_SENSORS_TSL2550=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
# CONFIG_SPI is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
CONFIG_W1=m
CONFIG_W1_CON=y

#
# 1-wire Bus Masters
#
# CONFIG_W1_MASTER_MATROX is not set
CONFIG_W1_MASTER_DS2490=m
CONFIG_W1_MASTER_DS2482=m

#
# 1-wire Slaves
#
CONFIG_W1_SLAVE_THERM=m
CONFIG_W1_SLAVE_SMEM=m
# CONFIG_W1_SLAVE_DS2431 is not set
CONFIG_W1_SLAVE_DS2433=m
CONFIG_W1_SLAVE_DS2433_CRC=y
CONFIG_W1_SLAVE_DS2760=m
# CONFIG_W1_SLAVE_BQ27000 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
# CONFIG_BATTERY_BQ27x00 is not set
CONFIG_HWMON=m
CONFIG_HWMON_VID=m
CONFIG_SENSORS_ABITUGURU=m
CONFIG_SENSORS_ABITUGURU3=m
CONFIG_SENSORS_AD7414=m
CONFIG_SENSORS_AD7418=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1026=m
CONFIG_SENSORS_ADM1029=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ADM9240=m
# CONFIG_SENSORS_ADT7462 is not set
CONFIG_SENSORS_ADT7470=m
CONFIG_SENSORS_ADT7473=m
# CONFIG_SENSORS_ADT7475 is not set
CONFIG_SENSORS_K8TEMP=m
CONFIG_SENSORS_ASB100=m
# CONFIG_SENSORS_ATK0110 is not set
CONFIG_SENSORS_ATXP1=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_I5K_AMB=m
CONFIG_SENSORS_F71805F=m
CONFIG_SENSORS_F71882FG=m
CONFIG_SENSORS_F75375S=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_FSCPOS=m
CONFIG_SENSORS_FSCHMD=m
# CONFIG_SENSORS_G760A is not set
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_GL520SM=m
CONFIG_SENSORS_CORETEMP=m
CONFIG_SENSORS_IBMAEM=m
CONFIG_SENSORS_IBMPEX=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM63=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_LM92=m
CONFIG_SENSORS_LM93=m
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LM95241 is not set
CONFIG_SENSORS_MAX1619=m
CONFIG_SENSORS_MAX6650=m
CONFIG_SENSORS_PC87360=m
CONFIG_SENSORS_PC87427=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_SIS5595=m
CONFIG_SENSORS_DME1737=m
CONFIG_SENSORS_SMSC47M1=m
CONFIG_SENSORS_SMSC47M192=m
CONFIG_SENSORS_SMSC47B397=m
CONFIG_SENSORS_ADS7828=m
CONFIG_SENSORS_THMC50=m
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_VT1211=m
CONFIG_SENSORS_VT8231=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83791D=m
CONFIG_SENSORS_W83792D=m
CONFIG_SENSORS_W83793=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83L786NG=m
CONFIG_SENSORS_W83627HF=m
CONFIG_SENSORS_W83627EHF=m
CONFIG_SENSORS_HDAPS=m
# CONFIG_SENSORS_LIS3LV02D is not set
CONFIG_SENSORS_APPLESMC=m
# CONFIG_HWMON_DEBUG_CHIP is not set
CONFIG_THERMAL=y
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=m
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
CONFIG_ALIM1535_WDT=m
CONFIG_ALIM7101_WDT=m
# CONFIG_SC520_WDT is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
CONFIG_IBMASR=m
# CONFIG_WAFER_WDT is not set
CONFIG_I6300ESB_WDT=m
CONFIG_ITCO_WDT=m
CONFIG_ITCO_VENDOR_SUPPORT=y
CONFIG_IT8712F_WDT=m
# CONFIG_IT87_WDT is not set
CONFIG_HP_WATCHDOG=m
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_SMSC_SCH311X_WDT is not set
# CONFIG_SMSC37B787_WDT is not set
CONFIG_W83627HF_WDT=m
CONFIG_W83697HF_WDT=m
# CONFIG_W83697UG_WDT is not set
CONFIG_W83877F_WDT=m
CONFIG_W83977F_WDT=m
CONFIG_MACHZ_WDT=m
# CONFIG_SBC_EPX_C3_WATCHDOG is not set

#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=m
CONFIG_WDTPCI=m
CONFIG_WDT_501_PCI=y

#
# USB-based Watchdog Cards
#
CONFIG_USBPCWATCHDOG=m
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
CONFIG_SSB=m
CONFIG_SSB_SPROM=y
CONFIG_SSB_PCIHOST_POSSIBLE=y
CONFIG_SSB_PCIHOST=y
# CONFIG_SSB_B43_PCI_BRIDGE is not set
CONFIG_SSB_PCMCIAHOST_POSSIBLE=y
CONFIG_SSB_PCMCIAHOST=y
# CONFIG_SSB_DEBUG is not set
CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
CONFIG_SSB_DRIVER_PCICORE=y

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
CONFIG_MFD_SM501=m
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_REGULATOR is not set

#
# Multimedia devices
#

#
# Multimedia core support
#
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L2_COMMON=m
CONFIG_VIDEO_ALLOW_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_DVB_CORE=m
CONFIG_VIDEO_MEDIA=m

#
# Multimedia drivers
#
CONFIG_VIDEO_SAA7146=m
CONFIG_VIDEO_SAA7146_VV=m
CONFIG_MEDIA_ATTACH=y
CONFIG_MEDIA_TUNER=m
# CONFIG_MEDIA_TUNER_CUSTOMISE is not set
CONFIG_MEDIA_TUNER_SIMPLE=m
CONFIG_MEDIA_TUNER_TDA8290=m
CONFIG_MEDIA_TUNER_TDA827X=m
CONFIG_MEDIA_TUNER_TDA18271=m
CONFIG_MEDIA_TUNER_TDA9887=m
CONFIG_MEDIA_TUNER_TEA5761=m
CONFIG_MEDIA_TUNER_TEA5767=m
CONFIG_MEDIA_TUNER_MT20XX=m
CONFIG_MEDIA_TUNER_MT2060=m
CONFIG_MEDIA_TUNER_MT2266=m
CONFIG_MEDIA_TUNER_MT2131=m
CONFIG_MEDIA_TUNER_QT1010=m
CONFIG_MEDIA_TUNER_XC2028=m
CONFIG_MEDIA_TUNER_XC5000=m
CONFIG_MEDIA_TUNER_MXL5005S=m
CONFIG_MEDIA_TUNER_MXL5007T=m
CONFIG_MEDIA_TUNER_MC44S803=m
CONFIG_VIDEO_V4L2=m
CONFIG_VIDEO_V4L1=m
CONFIG_VIDEOBUF_GEN=m
CONFIG_VIDEOBUF_DMA_SG=m
CONFIG_VIDEOBUF_VMALLOC=m
CONFIG_VIDEOBUF_DVB=m
CONFIG_VIDEO_BTCX=m
CONFIG_VIDEO_IR=m
CONFIG_VIDEO_TVEEPROM=m
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_CAPTURE_DRIVERS=y
# CONFIG_VIDEO_ADV_DEBUG is not set
# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
# CONFIG_VIDEO_HELPER_CHIPS_AUTO is not set
CONFIG_VIDEO_IR_I2C=m

#
# Encoders/decoders and other helper chips
#

#
# Audio decoders
#
CONFIG_VIDEO_TVAUDIO=m
CONFIG_VIDEO_TDA7432=m
CONFIG_VIDEO_TDA9840=m
CONFIG_VIDEO_TDA9875=m
CONFIG_VIDEO_TEA6415C=m
CONFIG_VIDEO_TEA6420=m
CONFIG_VIDEO_MSP3400=m
CONFIG_VIDEO_CS5345=m
CONFIG_VIDEO_CS53L32A=m
CONFIG_VIDEO_M52790=m
CONFIG_VIDEO_TLV320AIC23B=m
CONFIG_VIDEO_WM8775=m
CONFIG_VIDEO_WM8739=m
CONFIG_VIDEO_VP27SMPX=m

#
# RDS decoders
#
CONFIG_VIDEO_SAA6588=m

#
# Video decoders
#
CONFIG_VIDEO_BT819=m
CONFIG_VIDEO_BT856=m
CONFIG_VIDEO_BT866=m
CONFIG_VIDEO_KS0127=m
CONFIG_VIDEO_OV7670=m
CONFIG_VIDEO_TCM825X=m
CONFIG_VIDEO_SAA7110=m
CONFIG_VIDEO_SAA711X=m
CONFIG_VIDEO_SAA717X=m
CONFIG_VIDEO_SAA7191=m
# CONFIG_VIDEO_TVP514X is not set
CONFIG_VIDEO_TVP5150=m
CONFIG_VIDEO_VPX3220=m

#
# Video and audio decoders
#
CONFIG_VIDEO_CX25840=m

#
# MPEG video encoders
#
CONFIG_VIDEO_CX2341X=m

#
# Video encoders
#
CONFIG_VIDEO_SAA7127=m
CONFIG_VIDEO_SAA7185=m
CONFIG_VIDEO_ADV7170=m
CONFIG_VIDEO_ADV7175=m

#
# Video improvement chips
#
CONFIG_VIDEO_UPD64031A=m
CONFIG_VIDEO_UPD64083=m
# CONFIG_VIDEO_VIVI is not set
CONFIG_VIDEO_BT848=m
CONFIG_VIDEO_BT848_DVB=y
CONFIG_VIDEO_BWQCAM=m
CONFIG_VIDEO_CQCAM=m
CONFIG_VIDEO_W9966=m
CONFIG_VIDEO_CPIA=m
CONFIG_VIDEO_CPIA_PP=m
CONFIG_VIDEO_CPIA_USB=m
CONFIG_VIDEO_CPIA2=m
CONFIG_VIDEO_SAA5246A=m
CONFIG_VIDEO_SAA5249=m
CONFIG_VIDEO_STRADIS=m
CONFIG_VIDEO_ZORAN=m
CONFIG_VIDEO_ZORAN_DC30=m
CONFIG_VIDEO_ZORAN_ZR36060=m
CONFIG_VIDEO_ZORAN_BUZ=m
CONFIG_VIDEO_ZORAN_DC10=m
CONFIG_VIDEO_ZORAN_LML33=m
CONFIG_VIDEO_ZORAN_LML33R10=m
CONFIG_VIDEO_ZORAN_AVS6EYES=m
CONFIG_VIDEO_MEYE=m
CONFIG_VIDEO_SAA7134=m
CONFIG_VIDEO_SAA7134_ALSA=m
CONFIG_VIDEO_SAA7134_DVB=m
CONFIG_VIDEO_MXB=m
CONFIG_VIDEO_HEXIUM_ORION=m
CONFIG_VIDEO_HEXIUM_GEMINI=m
CONFIG_VIDEO_CX88=m
CONFIG_VIDEO_CX88_ALSA=m
CONFIG_VIDEO_CX88_BLACKBIRD=m
CONFIG_VIDEO_CX88_DVB=m
CONFIG_VIDEO_CX88_MPEG=m
CONFIG_VIDEO_CX88_VP3054=m
CONFIG_VIDEO_CX23885=m
CONFIG_VIDEO_AU0828=m
CONFIG_VIDEO_IVTV=m
CONFIG_VIDEO_FB_IVTV=m
CONFIG_VIDEO_CX18=m
# CONFIG_VIDEO_CAFE_CCIC is not set
CONFIG_SOC_CAMERA=m
CONFIG_SOC_CAMERA_MT9M001=m
# CONFIG_SOC_CAMERA_MT9M111 is not set
# CONFIG_SOC_CAMERA_MT9T031 is not set
CONFIG_SOC_CAMERA_MT9V022=m
# CONFIG_SOC_CAMERA_TW9910 is not set
CONFIG_SOC_CAMERA_PLATFORM=m
# CONFIG_SOC_CAMERA_OV772X is not set
CONFIG_V4L_USB_DRIVERS=y
CONFIG_USB_VIDEO_CLASS=m
CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
CONFIG_USB_GSPCA=m
# CONFIG_USB_M5602 is not set
# CONFIG_USB_STV06XX is not set
# CONFIG_USB_GSPCA_CONEX is not set
# CONFIG_USB_GSPCA_ETOMS is not set
# CONFIG_USB_GSPCA_FINEPIX is not set
# CONFIG_USB_GSPCA_MARS is not set
# CONFIG_USB_GSPCA_MR97310A is not set
# CONFIG_USB_GSPCA_OV519 is not set
# CONFIG_USB_GSPCA_OV534 is not set
# CONFIG_USB_GSPCA_PAC207 is not set
# CONFIG_USB_GSPCA_PAC7311 is not set
# CONFIG_USB_GSPCA_SONIXB is not set
# CONFIG_USB_GSPCA_SONIXJ is not set
# CONFIG_USB_GSPCA_SPCA500 is not set
# CONFIG_USB_GSPCA_SPCA501 is not set
# CONFIG_USB_GSPCA_SPCA505 is not set
# CONFIG_USB_GSPCA_SPCA506 is not set
# CONFIG_USB_GSPCA_SPCA508 is not set
# CONFIG_USB_GSPCA_SPCA561 is not set
# CONFIG_USB_GSPCA_SQ905 is not set
# CONFIG_USB_GSPCA_SQ905C is not set
# CONFIG_USB_GSPCA_STK014 is not set
# CONFIG_USB_GSPCA_SUNPLUS is not set
# CONFIG_USB_GSPCA_T613 is not set
# CONFIG_USB_GSPCA_TV8532 is not set
# CONFIG_USB_GSPCA_VC032X is not set
# CONFIG_USB_GSPCA_ZC3XX is not set
CONFIG_VIDEO_PVRUSB2=m
CONFIG_VIDEO_PVRUSB2_SYSFS=y
CONFIG_VIDEO_PVRUSB2_DVB=y
# CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set
CONFIG_VIDEO_HDPVR=m
CONFIG_VIDEO_EM28XX=m
CONFIG_VIDEO_EM28XX_ALSA=m
CONFIG_VIDEO_EM28XX_DVB=m
# CONFIG_VIDEO_CX231XX is not set
CONFIG_VIDEO_USBVISION=m
CONFIG_VIDEO_USBVIDEO=m
CONFIG_USB_VICAM=m
CONFIG_USB_IBMCAM=m
CONFIG_USB_KONICAWC=m
CONFIG_USB_QUICKCAM_MESSENGER=m
CONFIG_USB_ET61X251=m
CONFIG_VIDEO_OVCAMCHIP=m
CONFIG_USB_W9968CF=m
CONFIG_USB_OV511=m
CONFIG_USB_SE401=m
CONFIG_USB_SN9C102=m
CONFIG_USB_STV680=m
# CONFIG_USB_ZC0301 is not set
CONFIG_USB_PWC=m
# CONFIG_USB_PWC_DEBUG is not set
CONFIG_USB_PWC_INPUT_EVDEV=y
CONFIG_USB_ZR364XX=m
CONFIG_USB_STKWEBCAM=m
CONFIG_USB_S2255=m
CONFIG_RADIO_ADAPTERS=y
CONFIG_RADIO_GEMTEK_PCI=m
CONFIG_RADIO_MAXIRADIO=m
CONFIG_RADIO_MAESTRO=m
CONFIG_USB_DSBR=m
CONFIG_USB_SI470X=m
# CONFIG_USB_MR800 is not set
# CONFIG_RADIO_TEA5764 is not set
# CONFIG_DVB_DYNAMIC_MINORS is not set
CONFIG_DVB_CAPTURE_DRIVERS=y

#
# Supported SAA7146 based PCI Adapters
#
CONFIG_TTPCI_EEPROM=m
CONFIG_DVB_AV7110=m
CONFIG_DVB_AV7110_OSD=y
CONFIG_DVB_BUDGET_CORE=m
CONFIG_DVB_BUDGET=m
CONFIG_DVB_BUDGET_CI=m
CONFIG_DVB_BUDGET_AV=m
CONFIG_DVB_BUDGET_PATCH=m

#
# Supported USB Adapters
#
CONFIG_DVB_USB=m
# CONFIG_DVB_USB_DEBUG is not set
CONFIG_DVB_USB_A800=m
CONFIG_DVB_USB_DIBUSB_MB=m
# CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set
CONFIG_DVB_USB_DIBUSB_MC=m
CONFIG_DVB_USB_DIB0700=m
CONFIG_DVB_USB_UMT_010=m
CONFIG_DVB_USB_CXUSB=m
CONFIG_DVB_USB_M920X=m
CONFIG_DVB_USB_GL861=m
CONFIG_DVB_USB_AU6610=m
CONFIG_DVB_USB_DIGITV=m
CONFIG_DVB_USB_VP7045=m
CONFIG_DVB_USB_VP702X=m
CONFIG_DVB_USB_GP8PSK=m
CONFIG_DVB_USB_NOVA_T_USB2=m
CONFIG_DVB_USB_TTUSB2=m
CONFIG_DVB_USB_DTT200U=m
CONFIG_DVB_USB_OPERA1=m
CONFIG_DVB_USB_AF9005=m
CONFIG_DVB_USB_AF9005_REMOTE=m
CONFIG_DVB_USB_DW2102=m
# CONFIG_DVB_USB_CINERGY_T2 is not set
CONFIG_DVB_USB_ANYSEE=m
# CONFIG_DVB_USB_DTV5100 is not set
# CONFIG_DVB_USB_AF9015 is not set
# CONFIG_DVB_USB_CE6230 is not set
CONFIG_DVB_TTUSB_BUDGET=m
CONFIG_DVB_TTUSB_DEC=m
CONFIG_DVB_SIANO_SMS1XXX=m
CONFIG_DVB_SIANO_SMS1XXX_SMS_IDS=y

#
# Supported FlexCopII (B2C2) Adapters
#
CONFIG_DVB_B2C2_FLEXCOP=m
CONFIG_DVB_B2C2_FLEXCOP_PCI=m
CONFIG_DVB_B2C2_FLEXCOP_USB=m
# CONFIG_DVB_B2C2_FLEXCOP_DEBUG is not set

#
# Supported BT878 Adapters
#
CONFIG_DVB_BT8XX=m

#
# Supported Pluto2 Adapters
#
CONFIG_DVB_PLUTO2=m

#
# Supported SDMC DM1105 Adapters
#
# CONFIG_DVB_DM1105 is not set

#
# Supported DVB Frontends
#
# CONFIG_DVB_FE_CUSTOMISE is not set
CONFIG_DVB_STB0899=m
CONFIG_DVB_STB6100=m
CONFIG_DVB_CX24110=m
CONFIG_DVB_CX24123=m
CONFIG_DVB_MT312=m
CONFIG_DVB_ZL10036=m
CONFIG_DVB_S5H1420=m
CONFIG_DVB_STV0288=m
CONFIG_DVB_STB6000=m
CONFIG_DVB_STV0299=m
CONFIG_DVB_STV6110=m
CONFIG_DVB_STV0900=m
CONFIG_DVB_TDA8083=m
CONFIG_DVB_TDA10086=m
CONFIG_DVB_TDA8261=m
CONFIG_DVB_VES1X93=m
CONFIG_DVB_TUNER_ITD1000=m
CONFIG_DVB_TUNER_CX24113=m
CONFIG_DVB_TDA826X=m
CONFIG_DVB_TUA6100=m
CONFIG_DVB_CX24116=m
CONFIG_DVB_SI21XX=m
CONFIG_DVB_SP8870=m
CONFIG_DVB_SP887X=m
CONFIG_DVB_CX22700=m
CONFIG_DVB_CX22702=m
CONFIG_DVB_L64781=m
CONFIG_DVB_TDA1004X=m
CONFIG_DVB_NXT6000=m
CONFIG_DVB_MT352=m
CONFIG_DVB_ZL10353=m
CONFIG_DVB_DIB3000MB=m
CONFIG_DVB_DIB3000MC=m
CONFIG_DVB_DIB7000M=m
CONFIG_DVB_DIB7000P=m
CONFIG_DVB_TDA10048=m
CONFIG_DVB_VES1820=m
CONFIG_DVB_TDA10021=m
CONFIG_DVB_TDA10023=m
CONFIG_DVB_STV0297=m
CONFIG_DVB_NXT200X=m
CONFIG_DVB_OR51211=m
CONFIG_DVB_OR51132=m
CONFIG_DVB_BCM3510=m
CONFIG_DVB_LGDT330X=m
CONFIG_DVB_LGDT3305=m
CONFIG_DVB_S5H1409=m
CONFIG_DVB_AU8522=m
CONFIG_DVB_S5H1411=m
CONFIG_DVB_PLL=m
CONFIG_DVB_TUNER_DIB0070=m
CONFIG_DVB_LNBP21=m
CONFIG_DVB_ISL6405=m
CONFIG_DVB_ISL6421=m
CONFIG_DVB_LGS8GL5=m
CONFIG_DAB=y
CONFIG_USB_DABUSB=m

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_SIS=y
CONFIG_AGP_VIA=y
CONFIG_DRM=m
CONFIG_DRM_TDFX=m
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
CONFIG_DRM_I810=m
CONFIG_DRM_I830=m
CONFIG_DRM_I915=m
# CONFIG_DRM_I915_KMS is not set
CONFIG_DRM_MGA=m
CONFIG_DRM_SIS=m
CONFIG_DRM_VIA=m
CONFIG_DRM_SAVAGE=m
CONFIG_VGASTATE=m
CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
CONFIG_FB_DDC=m
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=y
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_SVGALIB=m
# CONFIG_FB_MACMODES is not set
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
CONFIG_FB_CIRRUS=m
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=m
# CONFIG_FB_UVESA is not set
CONFIG_FB_VESA=y
CONFIG_FB_EFI=y
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
CONFIG_FB_NVIDIA=m
CONFIG_FB_NVIDIA_I2C=y
# CONFIG_FB_NVIDIA_DEBUG is not set
CONFIG_FB_NVIDIA_BACKLIGHT=y
CONFIG_FB_RIVA=m
# CONFIG_FB_RIVA_I2C is not set
# CONFIG_FB_RIVA_DEBUG is not set
CONFIG_FB_RIVA_BACKLIGHT=y
# CONFIG_FB_LE80578 is not set
CONFIG_FB_INTEL=m
# CONFIG_FB_INTEL_DEBUG is not set
CONFIG_FB_INTEL_I2C=y
CONFIG_FB_MATROX=m
CONFIG_FB_MATROX_MILLENIUM=y
CONFIG_FB_MATROX_MYSTIQUE=y
CONFIG_FB_MATROX_G=y
CONFIG_FB_MATROX_I2C=m
CONFIG_FB_MATROX_MAVEN=m
CONFIG_FB_MATROX_MULTIHEAD=y
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
CONFIG_FB_ATY128=m
CONFIG_FB_ATY128_BACKLIGHT=y
CONFIG_FB_ATY=m
CONFIG_FB_ATY_CT=y
CONFIG_FB_ATY_GENERIC_LCD=y
CONFIG_FB_ATY_GX=y
CONFIG_FB_ATY_BACKLIGHT=y
CONFIG_FB_S3=m
CONFIG_FB_SAVAGE=m
CONFIG_FB_SAVAGE_I2C=y
CONFIG_FB_SAVAGE_ACCEL=y
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
CONFIG_FB_NEOMAGIC=m
CONFIG_FB_KYRO=m
CONFIG_FB_3DFX=m
CONFIG_FB_3DFX_ACCEL=y
CONFIG_FB_3DFX_I2C=y
CONFIG_FB_VOODOO1=m
# CONFIG_FB_VT8623 is not set
CONFIG_FB_TRIDENT=m
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
CONFIG_FB_SM501=m
# CONFIG_FB_VIRTUAL is not set
CONFIG_XEN_FBDEV_FRONTEND=y
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=m
# CONFIG_LCD_ILI9320 is not set
CONFIG_LCD_PLATFORM=m
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
CONFIG_BACKLIGHT_PROGEAR=m
CONFIG_BACKLIGHT_MBP_NVIDIA=m
# CONFIG_BACKLIGHT_SAHARA is not set

#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=m

#
# Display hardware drivers
#

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=m
CONFIG_SOUND_OSS_CORE=y
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_JACK=y
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
# CONFIG_SND_HRTIMER is not set
CONFIG_SND_DYNAMIC_MINORS=y
# CONFIG_SND_SUPPORT_OLD_API is not set
CONFIG_SND_VERBOSE_PROCFS=y
CONFIG_SND_VERBOSE_PRINTK=y
CONFIG_SND_DEBUG=y
# CONFIG_SND_DEBUG_VERBOSE is not set
CONFIG_SND_PCM_XRUN_DEBUG=y
CONFIG_SND_VMASTER=y
CONFIG_SND_MPU401_UART=m
CONFIG_SND_OPL3_LIB=m
CONFIG_SND_VX_LIB=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_DRIVERS=y
CONFIG_SND_PCSP=m
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
CONFIG_SND_MTS64=m
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m
CONFIG_SND_PORTMAN2X4=m
CONFIG_SND_AC97_POWER_SAVE=y
CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0
CONFIG_SND_SB_COMMON=m
CONFIG_SND_SB16_DSP=m
CONFIG_SND_PCI=y
CONFIG_SND_AD1889=m
CONFIG_SND_ALS300=m
CONFIG_SND_ALS4000=m
CONFIG_SND_ALI5451=m
CONFIG_SND_ATIIXP=m
CONFIG_SND_ATIIXP_MODEM=m
CONFIG_SND_AU8810=m
CONFIG_SND_AU8820=m
CONFIG_SND_AU8830=m
# CONFIG_SND_AW2 is not set
CONFIG_SND_AZT3328=m
CONFIG_SND_BT87X=m
# CONFIG_SND_BT87X_OVERCLOCK is not set
CONFIG_SND_CA0106=m
CONFIG_SND_CMIPCI=m
CONFIG_SND_OXYGEN_LIB=m
CONFIG_SND_OXYGEN=m
CONFIG_SND_CS4281=m
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
CONFIG_SND_CS5530=m
CONFIG_SND_DARLA20=m
CONFIG_SND_GINA20=m
CONFIG_SND_LAYLA20=m
CONFIG_SND_DARLA24=m
CONFIG_SND_GINA24=m
CONFIG_SND_LAYLA24=m
CONFIG_SND_MONA=m
CONFIG_SND_MIA=m
CONFIG_SND_ECHO3G=m
CONFIG_SND_INDIGO=m
CONFIG_SND_INDIGOIO=m
CONFIG_SND_INDIGODJ=m
# CONFIG_SND_INDIGOIOX is not set
# CONFIG_SND_INDIGODJX is not set
CONFIG_SND_EMU10K1=m
CONFIG_SND_EMU10K1X=m
CONFIG_SND_ENS1370=m
CONFIG_SND_ENS1371=m
CONFIG_SND_ES1938=m
CONFIG_SND_ES1968=m
CONFIG_SND_FM801=m
CONFIG_SND_FM801_TEA575X_BOOL=y
CONFIG_SND_FM801_TEA575X=m
CONFIG_SND_HDA_INTEL=m
CONFIG_SND_HDA_HWDEP=y
# CONFIG_SND_HDA_RECONFIG is not set
# CONFIG_SND_HDA_INPUT_BEEP is not set
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_ATIHDMI=y
CONFIG_SND_HDA_CODEC_NVHDMI=y
CONFIG_SND_HDA_CODEC_INTELHDMI=y
CONFIG_SND_HDA_ELD=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
CONFIG_SND_HDA_POWER_SAVE=y
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
CONFIG_SND_HDSP=m
CONFIG_SND_HDSPM=m
CONFIG_SND_HIFIER=m
CONFIG_SND_ICE1712=m
CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_KORG1212=m
CONFIG_SND_MAESTRO3=m
CONFIG_SND_MIXART=m
CONFIG_SND_NM256=m
CONFIG_SND_PCXHR=m
CONFIG_SND_RIPTIDE=m
CONFIG_SND_RME32=m
CONFIG_SND_RME96=m
CONFIG_SND_RME9652=m
CONFIG_SND_SONICVIBES=m
CONFIG_SND_TRIDENT=m
CONFIG_SND_VIA82XX=m
CONFIG_SND_VIA82XX_MODEM=m
CONFIG_SND_VIRTUOSO=m
CONFIG_SND_VX222=m
CONFIG_SND_YMFPCI=m
CONFIG_SND_USB=y
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_USX2Y=m
CONFIG_SND_USB_CAIAQ=m
CONFIG_SND_USB_CAIAQ_INPUT=y
# CONFIG_SND_USB_US122L is not set
# CONFIG_SND_PCMCIA is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=m
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_HID_DEBUG=y
CONFIG_HIDRAW=y

#
# USB Input Devices
#
CONFIG_USB_HID=y
CONFIG_HID_PID=y
CONFIG_USB_HIDDEV=y

#
# Special HID drivers
#
CONFIG_HID_A4TECH=y
CONFIG_HID_APPLE=y
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
CONFIG_HID_CYPRESS=y
# CONFIG_DRAGONRISE_FF is not set
CONFIG_HID_EZKEY=y
CONFIG_HID_KYE=y
CONFIG_HID_GYRATION=y
CONFIG_HID_KENSINGTON=y
CONFIG_HID_LOGITECH=y
CONFIG_LOGITECH_FF=y
CONFIG_LOGIRUMBLEPAD2_FF=y
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
CONFIG_HID_NTRIG=y
CONFIG_HID_PANTHERLORD=y
CONFIG_PANTHERLORD_FF=y
CONFIG_HID_PETALYNX=y
CONFIG_HID_SAMSUNG=y
CONFIG_HID_SONY=y
CONFIG_HID_SUNPLUS=y
# CONFIG_GREENASIA_FF is not set
CONFIG_HID_TOPSEED=y
CONFIG_THRUSTMASTER_FF=y
CONFIG_ZEROPLUS_FF=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB is not set
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_U132_HCD=m
CONFIG_USB_SL811_HCD=m
# CONFIG_USB_SL811_CS is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_WHCI_HCD is not set
# CONFIG_USB_HWA_HCD is not set

#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
CONFIG_USB_WDM=m
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_DATAFAB=m
CONFIG_USB_STORAGE_FREECOM=m
CONFIG_USB_STORAGE_ISD200=m
CONFIG_USB_STORAGE_USBAT=m
CONFIG_USB_STORAGE_SDDR09=m
CONFIG_USB_STORAGE_SDDR55=m
CONFIG_USB_STORAGE_JUMPSHOT=m
CONFIG_USB_STORAGE_ALAUDA=m
CONFIG_USB_STORAGE_ONETOUCH=m
CONFIG_USB_STORAGE_KARMA=m
CONFIG_USB_STORAGE_CYPRESS_ATACB=m
# CONFIG_USB_LIBUSUAL is not set

#
# USB Imaging devices
#
CONFIG_USB_MDC800=m
CONFIG_USB_MICROTEK=m

#
# USB port drivers
#
CONFIG_USB_USS720=m
CONFIG_USB_SERIAL=m
CONFIG_USB_EZUSB=y
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_AIRCABLE=m
CONFIG_USB_SERIAL_ARK3116=m
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_CH341=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
# CONFIG_USB_SERIAL_CP210X is not set
CONFIG_USB_SERIAL_CYPRESS_M8=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_FUNSOFT=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
# CONFIG_USB_SERIAL_GARMIN is not set
CONFIG_USB_SERIAL_IPW=m
CONFIG_USB_SERIAL_IUU=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_MOS7720=m
CONFIG_USB_SERIAL_MOS7840=m
CONFIG_USB_SERIAL_MOTOROLA=m
CONFIG_USB_SERIAL_NAVMAN=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_OTI6858=m
# CONFIG_USB_SERIAL_QUALCOMM is not set
CONFIG_USB_SERIAL_SPCP8X5=m
CONFIG_USB_SERIAL_HP4X=m
CONFIG_USB_SERIAL_SAFE=m
CONFIG_USB_SERIAL_SAFE_PADDED=y
# CONFIG_USB_SERIAL_SIEMENS_MPI is not set
CONFIG_USB_SERIAL_SIERRAWIRELESS=m
# CONFIG_USB_SERIAL_SYMBOL is not set
CONFIG_USB_SERIAL_TI=m
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_OPTION=m
CONFIG_USB_SERIAL_OMNINET=m
# CONFIG_USB_SERIAL_OPTICON is not set
CONFIG_USB_SERIAL_DEBUG=m

#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI62=m
CONFIG_USB_EMI26=m
CONFIG_USB_ADUTUX=m
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
CONFIG_USB_LEGOTOWER=m
CONFIG_USB_LCD=m
CONFIG_USB_BERRY_CHARGE=m
CONFIG_USB_LED=m
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
CONFIG_USB_IDMOUSE=m
CONFIG_USB_FTDI_ELAN=m
CONFIG_USB_APPLEDISPLAY=m
CONFIG_USB_SISUSBVGA=m
CONFIG_USB_SISUSBVGA_CON=y
CONFIG_USB_LD=m
CONFIG_USB_TRANCEVIBRATOR=m
CONFIG_USB_IOWARRIOR=m
# CONFIG_USB_TEST is not set
CONFIG_USB_ISIGHTFW=m
# CONFIG_USB_VST is not set
CONFIG_USB_ATM=m
CONFIG_USB_SPEEDTOUCH=m
CONFIG_USB_CXACRU=m
CONFIG_USB_UEAGLEATM=m
CONFIG_USB_XUSBATM=m
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_UWB is not set
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=m
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_SDIO_UART=m
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_SDHCI=m
CONFIG_MMC_SDHCI_PCI=m
CONFIG_MMC_RICOH_MMC=m
CONFIG_MMC_WBSD=m
CONFIG_MMC_TIFM_SD=m
CONFIG_MMC_SDRICOH_CS=m
CONFIG_MEMSTICK=m
# CONFIG_MEMSTICK_DEBUG is not set

#
# MemoryStick drivers
#
# CONFIG_MEMSTICK_UNSAFE_RESUME is not set
CONFIG_MSPRO_BLOCK=m

#
# MemoryStick Host Controller Drivers
#
CONFIG_MEMSTICK_TIFM_MS=m
CONFIG_MEMSTICK_JMICRON_38X=m
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_ALIX2 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_LP5521 is not set
CONFIG_LEDS_CLEVO_MAIL=m
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_BD2802 is not set

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_HEARTBEAT=m
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
CONFIG_LEDS_TRIGGER_DEFAULT_ON=m

#
# iptables trigger is under Netfilter config (LED target)
#
CONFIG_ACCESSIBILITY=y
CONFIG_A11Y_BRAILLE_CONSOLE=y
CONFIG_INFINIBAND=m
CONFIG_INFINIBAND_USER_MAD=m
CONFIG_INFINIBAND_USER_ACCESS=m
CONFIG_INFINIBAND_USER_MEM=y
CONFIG_INFINIBAND_ADDR_TRANS=y
CONFIG_INFINIBAND_MTHCA=m
CONFIG_INFINIBAND_MTHCA_DEBUG=y
CONFIG_INFINIBAND_IPATH=m
CONFIG_INFINIBAND_AMSO1100=m
# CONFIG_INFINIBAND_AMSO1100_DEBUG is not set
CONFIG_INFINIBAND_CXGB3=m
# CONFIG_INFINIBAND_CXGB3_DEBUG is not set
CONFIG_MLX4_INFINIBAND=m
CONFIG_INFINIBAND_NES=m
# CONFIG_INFINIBAND_NES_DEBUG is not set
CONFIG_INFINIBAND_IPOIB=m
CONFIG_INFINIBAND_IPOIB_CM=y
CONFIG_INFINIBAND_IPOIB_DEBUG=y
CONFIG_INFINIBAND_IPOIB_DEBUG_DATA=y
CONFIG_INFINIBAND_SRP=m
CONFIG_INFINIBAND_ISER=m
CONFIG_EDAC=y

#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_MM_EDAC=m
CONFIG_EDAC_E752X=m
CONFIG_EDAC_I82975X=m
CONFIG_EDAC_I3000=m
# CONFIG_EDAC_X38 is not set
# CONFIG_EDAC_I5400 is not set
CONFIG_EDAC_I5000=m
CONFIG_EDAC_I5100=m
# CONFIG_EDAC_AMD8131 is not set
# CONFIG_EDAC_AMD8111 is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=m
CONFIG_RTC_DRV_DS1374=m
CONFIG_RTC_DRV_DS1672=m
CONFIG_RTC_DRV_MAX6900=m
CONFIG_RTC_DRV_RS5C372=m
CONFIG_RTC_DRV_ISL1208=m
CONFIG_RTC_DRV_X1205=m
CONFIG_RTC_DRV_PCF8563=m
CONFIG_RTC_DRV_PCF8583=m
CONFIG_RTC_DRV_M41T80=m
CONFIG_RTC_DRV_M41T80_WDT=y
# CONFIG_RTC_DRV_S35390A is not set
CONFIG_RTC_DRV_FM3130=m
# CONFIG_RTC_DRV_RX8581 is not set

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
# CONFIG_RTC_DRV_DS1286 is not set
CONFIG_RTC_DRV_DS1511=m
CONFIG_RTC_DRV_DS1553=m
CONFIG_RTC_DRV_DS1742=m
CONFIG_RTC_DRV_STK17TA8=m
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
CONFIG_RTC_DRV_M48T59=m
# CONFIG_RTC_DRV_BQ4802 is not set
CONFIG_RTC_DRV_V3020=m

#
# on-CPU RTC drivers
#
CONFIG_DMADEVICES=y

#
# DMA Devices
#
CONFIG_INTEL_IOATDMA=m
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
CONFIG_NET_DMA=y
# CONFIG_ASYNC_TX_DMA is not set
# CONFIG_DMATEST is not set
CONFIG_DCA=m
CONFIG_AUXDISPLAY=y
CONFIG_KS0108=m
CONFIG_KS0108_PORT=0x378
CONFIG_KS0108_DELAY=2
CONFIG_CFAG12864B=m
CONFIG_CFAG12864B_RATE=20
CONFIG_UIO=m
CONFIG_UIO_CIF=m
CONFIG_UIO_PDRV=m
CONFIG_UIO_PDRV_GENIRQ=m
CONFIG_UIO_SMX=m
# CONFIG_UIO_AEC is not set
# CONFIG_UIO_SERCOS3 is not set
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
# CONFIG_STAGING is not set
CONFIG_X86_PLATFORM_DEVICES=y
CONFIG_ACER_WMI=m
CONFIG_ASUS_LAPTOP=m
# CONFIG_DELL_WMI is not set
CONFIG_FUJITSU_LAPTOP=m
# CONFIG_FUJITSU_LAPTOP_DEBUG is not set
CONFIG_HP_WMI=m
CONFIG_MSI_LAPTOP=m
# CONFIG_PANASONIC_LAPTOP is not set
CONFIG_COMPAL_LAPTOP=m
CONFIG_SONY_LAPTOP=m
CONFIG_SONYPI_COMPAT=y
CONFIG_THINKPAD_ACPI=m
# CONFIG_THINKPAD_ACPI_DEBUGFACILITIES is not set
# CONFIG_THINKPAD_ACPI_DEBUG is not set
# CONFIG_THINKPAD_ACPI_UNSAFE_LEDS is not set
CONFIG_THINKPAD_ACPI_BAY=y
CONFIG_THINKPAD_ACPI_VIDEO=y
CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y
# CONFIG_INTEL_MENLOW is not set
# CONFIG_EEEPC_LAPTOP is not set
CONFIG_ACPI_WMI=m
# CONFIG_ACPI_ASUS is not set
CONFIG_ACPI_TOSHIBA=m

#
# Firmware Drivers
#
CONFIG_EDD=m
# CONFIG_EDD_OFF is not set
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_EFI_VARS=y
CONFIG_DELL_RBU=m
CONFIG_DCDBAS=m
CONFIG_DMIID=y
CONFIG_ISCSI_IBFT_FIND=y
CONFIG_ISCSI_IBFT=m

#
# File systems
#
CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT2_FS_XIP=y
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4_FS=m
CONFIG_EXT4DEV_COMPAT=y
CONFIG_EXT4_FS_XATTR=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
CONFIG_FS_XIP=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=m
CONFIG_JBD2_DEBUG=y
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_REISERFS_FS_SECURITY=y
CONFIG_JFS_FS=m
CONFIG_JFS_POSIX_ACL=y
CONFIG_JFS_SECURITY=y
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_FILE_LOCKING=y
CONFIG_XFS_FS=m
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_DEBUG is not set
CONFIG_GFS2_FS=m
# CONFIG_GFS2_FS_LOCKING_DLM is not set
CONFIG_OCFS2_FS=m
CONFIG_OCFS2_FS_O2CB=m
CONFIG_OCFS2_FS_USERSPACE_CLUSTER=m
# CONFIG_OCFS2_FS_STATS is not set
# CONFIG_OCFS2_DEBUG_MASKLOG is not set
# CONFIG_OCFS2_DEBUG_FS is not set
# CONFIG_OCFS2_FS_POSIX_ACL is not set
# CONFIG_BTRFS_FS is not set
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
CONFIG_QUOTA_NETLINK_INTERFACE=y
# CONFIG_PRINT_QUOTA_WARNING is not set
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m
CONFIG_GENERIC_ACL=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_CONFIGFS_FS=m
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
CONFIG_AFFS_FS=m
CONFIG_ECRYPT_FS=m
CONFIG_HFS_FS=m
CONFIG_HFSPLUS_FS=m
CONFIG_BEFS_FS=m
# CONFIG_BEFS_DEBUG is not set
CONFIG_BFS_FS=m
CONFIG_EFS_FS=m
CONFIG_JFFS2_FS=m
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_FS_WBUF_VERIFY is not set
CONFIG_JFFS2_SUMMARY=y
CONFIG_JFFS2_FS_XATTR=y
CONFIG_JFFS2_FS_POSIX_ACL=y
CONFIG_JFFS2_FS_SECURITY=y
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
# CONFIG_JFFS2_LZO is not set
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
CONFIG_UBIFS_FS=m
CONFIG_UBIFS_FS_XATTR=y
# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
# CONFIG_UBIFS_FS_DEBUG is not set
CONFIG_CRAMFS=m
CONFIG_SQUASHFS=m
# CONFIG_SQUASHFS_EMBEDDED is not set
CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3
CONFIG_VXFS_FS=m
CONFIG_MINIX_FS=m
CONFIG_OMFS_FS=m
# CONFIG_HPFS_FS is not set
CONFIG_QNX4FS_FS=m
CONFIG_ROMFS_FS=m
CONFIG_ROMFS_BACKED_BY_BLOCK=y
# CONFIG_ROMFS_BACKED_BY_MTD is not set
# CONFIG_ROMFS_BACKED_BY_BOTH is not set
CONFIG_ROMFS_ON_BLOCK=y
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set
# CONFIG_UFS_DEBUG is not set
# CONFIG_NILFS2_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_SUNRPC_XPRT_RDMA=m
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_RPCSEC_GSS_SPKM3=m
# CONFIG_SMB_FS is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
CONFIG_CIFS_WEAK_PW_HASH=y
CONFIG_CIFS_UPCALL=y
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_DEBUG2 is not set
CONFIG_CIFS_DFS_UPCALL=y
CONFIG_CIFS_EXPERIMENTAL=y
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
CONFIG_CODA_FS=m
# CONFIG_AFS_FS is not set
CONFIG_9P_FS=m

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m
CONFIG_DLM=m
CONFIG_DLM_DEBUG=y

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_LIST=y
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
CONFIG_BOOT_PRINTK_DELAY=y
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_LKDTM is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
# CONFIG_SYSCTL_SYSCALL_CHECK is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_FTRACE_SYSCALLS=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_RING_BUFFER=y
CONFIG_TRACING=y
CONFIG_TRACING_SUPPORT=y

#
# Tracers
#
# CONFIG_FUNCTION_TRACER is not set
CONFIG_IRQSOFF_TRACER=y
CONFIG_SYSPROF_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_CONTEXT_SWITCH_TRACER=y
# CONFIG_EVENT_TRACER is not set
# CONFIG_FTRACE_SYSCALLS is not set
# CONFIG_BOOT_TRACER is not set
# CONFIG_TRACE_BRANCH_PROFILING is not set
# CONFIG_POWER_TRACER is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_KMEMTRACE is not set
# CONFIG_WORKQUEUE_TRACER is not set
CONFIG_BLK_DEV_IO_TRACE=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_MMIOTRACE is not set
CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
# CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set
CONFIG_BUILD_DOCSRC=y
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
CONFIG_KGDB_TESTS=y
# CONFIG_KGDB_TESTS_ON_BOOT is not set
CONFIG_STRICT_DEVMEM=y
# CONFIG_X86_VERBOSE_BOOTUP is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_EARLY_PRINTK_DBGP is not set
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_X86_PTDUMP is not set
CONFIG_DEBUG_RODATA=y
# CONFIG_DEBUG_RODATA_TEST is not set
# CONFIG_DEBUG_NX_TEST is not set
# CONFIG_IOMMU_DEBUG is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_DEBUG_BOOT_PARAMS=y
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
# CONFIG_SECURITY_PATH is not set
CONFIG_SECURITY_FILE_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=65536
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_IMA is not set
CONFIG_XOR_BLOCKS=m
CONFIG_ASYNC_CORE=m
CONFIG_ASYNC_MEMCPY=m
CONFIG_ASYNC_XOR=m
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_FIPS=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_TEST=m

#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
CONFIG_CRYPTO_SEQIV=m

#
# Block modes
#
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_CTR=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m

#
# Digest
#
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_CRC32C_INTEL is not set
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_RMD128=m
CONFIG_CRYPTO_RMD160=m
CONFIG_CRYPTO_RMD256=m
CONFIG_CRYPTO_RMD320=m
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m

#
# Ciphers
#
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_X86_64=m
# CONFIG_CRYPTO_AES_NI_INTEL is not set
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
# CONFIG_CRYPTO_SALSA20 is not set
CONFIG_CRYPTO_SALSA20_X86_64=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_TEA=m
# CONFIG_CRYPTO_TWOFISH is not set
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_X86_64=m

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
# CONFIG_CRYPTO_ZLIB is not set
CONFIG_CRYPTO_LZO=m

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_HIFN_795X=m
CONFIG_CRYPTO_DEV_HIFN_795X_RNG=y
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m
CONFIG_KVM_TRACE=y
CONFIG_VIRTIO=m
CONFIG_VIRTIO_RING=m
CONFIG_VIRTIO_PCI=m
CONFIG_VIRTIO_BALLOON=m
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_LZO_COMPRESS=m
CONFIG_LZO_DECOMPRESS=m
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_REED_SOLOMON=m
CONFIG_REED_SOLOMON_DEC16=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_NLATTR=y

Re: [patch 00/13] devtmpfs patches

[Greg KH]

On Mon, May 11, 2009 at 01:40:30PM -0400, David P. Quigley wrote:
> I took the patches and applied them to Linus' tree and installed the
> kernel on a Fedora 10 box with SELinux enabled and it oopses on startup.
> The oops happens every time I boot up so I can reproduce it as needed to
> help fix it. I've attached my kernel config in case that helps and have
> pasted the oops below. If needed I can provide the entire dmesg output.

If you disable selinux at the boot command line, does this oops not
happen?

thanks for testing and reporting this,

greg k-h

Re: [patch 00/13] devtmpfs patches

[David P. Quigley]

On Mon, 2009-05-11 at 10:56 -0700, Greg KH wrote:
> On Mon, May 11, 2009 at 01:40:30PM -0400, David P. Quigley wrote:
> > I took the patches and applied them to Linus' tree and installed the
> > kernel on a Fedora 10 box with SELinux enabled and it oopses on startup.
> > The oops happens every time I boot up so I can reproduce it as needed to
> > help fix it. I've attached my kernel config in case that helps and have
> > pasted the oops below. If needed I can provide the entire dmesg output.
> 
> If you disable selinux at the boot command line, does this oops not
> happen?
> 
> thanks for testing and reporting this,
> 
> greg k-h

So if I boot SELinux with enforcing mode turned off (enforcing=0) it
boots without oopsing. I would assume that booting with SELinux
completely disabled does the same thing. I narrowed it down to this one
system call.

----
type=SYSCALL msg=audit(05/11/2009 14:07:11.756:4) : arch=x86_64 syscall=open success=yes exit=3 a0=7fffaf25dfe0 a1=2 a2=0 a3=8 items=0 ppid=1 pid=2329 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=tty5 ses=4294967295 comm=mingetty exe=/sbin/mingetty subj=system_u:system_r:getty_t:s0 key=(null) 
type=AVC msg=audit(05/11/2009 14:07:11.756:4) : avc:  denied  { create } for  pid=2329 comm=mingetty name=vcs5 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file 
type=AVC msg=audit(05/11/2009 14:07:11.756:4) : avc:  denied  { add_name } for  pid=2329 comm=mingetty name=vcs5 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir 
type=AVC msg=audit(05/11/2009 14:07:11.756:4) : avc:  denied  { mknod } for  pid=2329 comm=mingetty capability=mknod scontext=system_u:system_r:getty_t:s0 tcontext=system_u:system_r:getty_t:s0 tclass=capability 
type=AVC msg=audit(05/11/2009 14:07:11.756:4) : avc:  denied  { write } for  pid=2329 comm=mingetty name=/ dev=tmpfs ino=4 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir 
----

Basically what this means is that getty attempted an open system call
which would have failed with an SELinux permission denial. What I think
might be happening here is that getty tries to open the tty device and
the devtmpfs kicks in and tries to create the tty devices. The problem
is in doing this it uses the credentials of the current process which in
this case is getty, and since it is trying to create them on a tmpfs
instead of a directory labeled properly it is failing. Now even if these
permissions fail it shouldn't be possible to bug the kernel with it.
This makes me think that there is a problem some where in the error
handling code.

This however does highlight a problem with the fact that device node
labeling isn't being done properly. It should be possible to create this
fs with a different name such that it doesn't appear as a tmpfs file
system to SELinux. If it appears as a devtmpfs file system then we can
specify the root label and labels on the other devices properly in
policy. Also it is concerning that creating the node is being done with
the credentials of the current process because it means that
applications which have no business creating device nodes will have to
have policy allowing them to do so. 

Dave

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Mon, May 11, 2009 at 22:41, David P. Quigley <dpquigl@tycho.nsa.gov> wrote:

> This however does highlight a problem with the fact that device node
> labeling isn't being done properly. It should be possible to create this
> fs with a different name such that it doesn't appear as a tmpfs file
> system to SELinux. If it appears as a devtmpfs file system then we can
> specify the root label and labels on the other devices properly in
> policy.

That could be done, if it solves this problem. Damn, now we have the
naming problem back again. :)

By doing its own fstype, we could also make the auto-mount optional,
because you could always reach the filesystem anytime later.

A different fstype has the slight inconvenience, that existing
userspace needs to be taught to handle it explicitly, while a tmfps is
already handled automatically because we use tmpfs already today. But
that may not be too important.

Thanks a lot for your tests and analysis,
Kay

Re: [patch 00/13] devtmpfs patches

[Alan Cox]

> By doing its own fstype, we could also make the auto-mount optional,
> because you could always reach the filesystem anytime later.

Killing the automount would also fix a lot of the other problems as you
can then mount it in the initrd and dump it when you have the real fs up,
or you can mount it privately thanks to Al Viro's magic with mount points
and only the daemon that must make the "real" device file system need
have it mounted and accessible.

> A different fstype has the slight inconvenience, that existing
> userspace needs to be taught to handle it explicitly, while a tmfps is
> already handled automatically because we use tmpfs already today. But
> that may not be too important.

Thats a good thing - it stops some of the suprise behaviour the Eric
pointed out and objected to.

> Thanks a lot for your tests and analysis,

And I think btw the underlying failure was in the tty layer - I just need
to find it. It's the second report vaguely of this form so something is
lurking in the stygian depths.

Alan

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Mon, May 11, 2009 at 23:19, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> By doing its own fstype, we could also make the auto-mount optional,
>> because you could always reach the filesystem anytime later.
>
> Killing the automount would also fix a lot of the other problems as you
> can then mount it in the initrd and dump it when you have the real fs up,
> or you can mount it privately thanks to Al Viro's magic with mount points
> and only the daemon that must make the "real" device file system need
> have it mounted and accessible.

Sounds good.

>> A different fstype has the slight inconvenience, that existing
>> userspace needs to be taught to handle it explicitly, while a tmfps is
>> already handled automatically because we use tmpfs already today. But
>> that may not be too important.
>
> Thats a good thing - it stops some of the suprise behaviour the Eric
> pointed out and objected to.

I'll give it try. Any name suggestions to throw at that thing? :)

>> Thanks a lot for your tests and analysis,
>
> And I think btw the underlying failure was in the tty layer - I just need
> to find it. It's the second report vaguely of this form so something is
> lurking in the stygian depths.

Ah, good. So that was a useful outcome of it at least. :)

Thanks,
Kay

Re: [patch 00/13] devtmpfs patches

[Stephen Smalley]

On Mon, 2009-05-11 at 23:05 +0200, Kay Sievers wrote:
> On Mon, May 11, 2009 at 22:41, David P. Quigley <dpquigl@tycho.nsa.gov> wrote:
> 
> > This however does highlight a problem with the fact that device node
> > labeling isn't being done properly. It should be possible to create this
> > fs with a different name such that it doesn't appear as a tmpfs file
> > system to SELinux. If it appears as a devtmpfs file system then we can
> > specify the root label and labels on the other devices properly in
> > policy.
> 
> That could be done, if it solves this problem. Damn, now we have the
> naming problem back again. :)
> 
> By doing its own fstype, we could also make the auto-mount optional,
> because you could always reach the filesystem anytime later.
> 
> A different fstype has the slight inconvenience, that existing
> userspace needs to be taught to handle it explicitly, while a tmfps is
> already handled automatically because we use tmpfs already today. But
> that may not be too important.
> 
> Thanks a lot for your tests and analysis,

I don't think merely changing the fstype will suffice; that merely lets
us assign a different default security context to inodes in the
filesystem (e.g. device_t vs tmpfs_t), but doesn't address the fact that
use of devtmpfs rather than just udev seems to alter the permission
checking upon an open(2) by mingetty, thereby breaking existing
policies.  Previously mingetty didn't require permissions to mknod; with
devtmpfs, it does.  I'm wondering if devtmpfs is internally performing
operations that ought to be done in kernel context rather than the
context of the userspace process that initiated the open(2).

Also, I was wondering why the existing restorecon -R /dev that is
performed by /etc/rc.sysinit to fix up the security contexts on the
initial /dev tree prior to policy load doesn't seem to be getting
applied when devtmpfs is enabled.  Does devtmpfs pass through setxattr()
requests to the underlying tmpfs mount?

-- 
Stephen Smalley
National Security Agency

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Tue, May 12, 2009 at 14:45, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> I don't think merely changing the fstype will suffice; that merely lets
> us assign a different default security context to inodes in the
> filesystem (e.g. device_t vs tmpfs_t), but doesn't address the fact that
> use of devtmpfs rather than just udev seems to alter the permission
> checking upon an open(2) by mingetty, thereby breaking existing
> policies.

It will be its own filesystem type and no longer be auto-mounted in
initramfs at all. There is an option to request an auto-mount it for
the case the kernel mounted the rootfs. This is to allow the rescue
setup to work.

> Previously mingetty didn't require permissions to mknod; with
> devtmpfs, it does.  I'm wondering if devtmpfs is internally performing
> operations that ought to be done in kernel context rather than the
> context of the userspace process that initiated the open(2).

How may that look like?

> Also, I was wondering why the existing restorecon -R /dev that is
> performed by /etc/rc.sysinit to fix up the security contexts on the
> initial /dev tree prior to policy load doesn't seem to be getting
> applied when devtmpfs is enabled.  Does devtmpfs pass through setxattr()
> requests to the underlying tmpfs mount?

It's a plain tmpfs, nothing different from a manual mounted one, just
that the kernel has created the instance and remembered the vfs mount
to put stuff into it, regardless of where is is mounted, or maybe not
mounted at all.

Thanks,
Kay

Re: [patch 00/13] devtmpfs patches

[Stephen Smalley]

On Tue, 2009-05-12 at 17:10 +0200, Kay Sievers wrote:
> On Tue, May 12, 2009 at 14:45, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
> > I don't think merely changing the fstype will suffice; that merely lets
> > us assign a different default security context to inodes in the
> > filesystem (e.g. device_t vs tmpfs_t), but doesn't address the fact that
> > use of devtmpfs rather than just udev seems to alter the permission
> > checking upon an open(2) by mingetty, thereby breaking existing
> > policies.
> 
> It will be its own filesystem type and no longer be auto-mounted in
> initramfs at all. There is an option to request an auto-mount it for
> the case the kernel mounted the rootfs. This is to allow the rescue
> setup to work.
> 
> > Previously mingetty didn't require permissions to mknod; with
> > devtmpfs, it does.  I'm wondering if devtmpfs is internally performing
> > operations that ought to be done in kernel context rather than the
> > context of the userspace process that initiated the open(2).
> 
> How may that look like?

I think the issue is that the devtmpfs functions are calling vfs helpers
to create and unlink the device nodes, and those helpers apply
permission checks based on the current process' credentials.  I think a
similar issue arose in sysfs a while ago.  Options are to either bypass
the vfs helpers to avoid that permission checking for what I think are
intended to be kernel-internal operations, or to override credentials
temporarily around the calls to the vfs helpers, ala:
new_cred = prepare_kernel_cred(NULL); 
old_cred  = override_creds(new_cred);
rc = vfs_mknod(...);
revert_creds(old_cred);

> > Also, I was wondering why the existing restorecon -R /dev that is
> > performed by /etc/rc.sysinit to fix up the security contexts on the
> > initial /dev tree prior to policy load doesn't seem to be getting
> > applied when devtmpfs is enabled.  Does devtmpfs pass through setxattr()
> > requests to the underlying tmpfs mount?
> 
> It's a plain tmpfs, nothing different from a manual mounted one, just
> that the kernel has created the instance and remembered the vfs mount
> to put stuff into it, regardless of where is is mounted, or maybe not
> mounted at all.
> 
> Thanks,
> Kay
-- 
Stephen Smalley
National Security Agency

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Tue, May 12, 2009 at 17:35, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> I think the issue is that the devtmpfs functions are calling vfs helpers
> to create and unlink the device nodes, and those helpers apply
> permission checks based on the current process' credentials.  I think a
> similar issue arose in sysfs a while ago.  Options are to either bypass
> the vfs helpers to avoid that permission checking for what I think are
> intended to be kernel-internal operations, or to override credentials
> temporarily around the calls to the vfs helpers, ala:
> new_cred = prepare_kernel_cred(NULL);
> old_cred  = override_creds(new_cred);
> rc = vfs_mknod(...);
> revert_creds(old_cred);

Ah, I see. That's probably what stuff like this is for:

 /**
  * lookup_one_noperm - bad hack for sysfs
  * @name:       pathname component to lookup
  * @base:       base directory to lookup from
  *
  * This is a variant of lookup_one_len that doesn't perform any permission
  * checks.   It's a horrible hack to work around the braindead sysfs
  * architecture and should not be used anywhere else.
  *
  * DON'T USE THIS FUNCTION EVER, thanks.
  */
  struct dentry *lookup_one_noperm(const char *name, struct dentry *base)

Thanks,
Kay

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Tue, 2009-05-12 at 17:54 +0200, Kay Sievers wrote:
> On Tue, May 12, 2009 at 17:35, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
> > I think the issue is that the devtmpfs functions are calling vfs helpers
> > to create and unlink the device nodes, and those helpers apply
> > permission checks based on the current process' credentials.  I think a
> > similar issue arose in sysfs a while ago.  Options are to either bypass
> > the vfs helpers to avoid that permission checking for what I think are
> > intended to be kernel-internal operations, or to override credentials
> > temporarily around the calls to the vfs helpers, ala:
> > new_cred = prepare_kernel_cred(NULL);
> > old_cred  = override_creds(new_cred);
> > rc = vfs_mknod(...);
> > revert_creds(old_cred);
> 
> Ah, I see.

Here is the current state of the patch. It would be great, if you can
have a quick look, if that matches what you meant. It runs fine here,
but I didn't try any security enforcing software so far, which might run
into trouble without the credential stuff.

Thanks a lot,
Kay


From: Kay Sievers <kay.sievers@vrfy.org>
Subject: Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

Devtmpfs lets the kernel create a tmpfs instance called devtmpfs
very early at kernel initialization, before any driver-core device
is registered. Every device with a major/minor will create a
device node in devtmpfs.

Devtmpfs can be changed and altered by userspace at any time,
and in any way needed - just like today's udev-mounted tmpfs. Unmodified
udev versions will run just fine on top of it, and will recognize an
already existing kernel-created device node and use it.

The default node permissions are root:root 0600. Proper permissions
and user/group ownership, meaningful symlinks, all other policy besides
the node name, still needs to be applied by udev, just as without
devtmpfs.

If a node is created by devtmps, devtmpfs will remove the device node
when the device goes away. If the device node was created by
userspace, or the devtmpfs created node was replaced by userspace, it
will not be removed by devtmpfs.

If automatically mounted, it makes init=/bin/sh work without any
further userspace support. /dev will be fully populated and dynamic,
and always reflect the current device state of the kernel. Especially
in the face of the already implemented dynamic device numbers, this
can be very helpful in a rescue situation, where static devices nodes
may no longer work correctly.
Custom, embedded-like systems should be able to use this as a dynamic
/dev directory without any need for aditional userspace tools.

With the kernel populated /dev, existing initramfs or kernel-mount
bootup logic can be optimized to be more efficient, and not to require a
full coldplug run, which is currently needed to bootstrap the inital
/dev directory content, before continuing bringing up the rest of
the system. There will be no missed events to replay, because /dev is
available before the first kernel device is registered with the
driver-core.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/base/Kconfig     |   25 ++
 drivers/base/Makefile    |    1 
 drivers/base/base.h      |    6 
 drivers/base/core.c      |    3 
 drivers/base/devtmpfs.c  |  405 +++++++++++++++++++++++++++++++++++++++++++++++
 drivers/base/init.c      |    1 
 include/linux/device.h   |   10 +
 include/linux/shmem_fs.h |    2 
 init/do_mounts.c         |    2 
 init/main.c              |    2 
 mm/shmem.c               |    6 
 11 files changed, 458 insertions(+), 5 deletions(-)

--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -8,6 +8,31 @@ config UEVENT_HELPER_PATH
 	  Path to uevent helper program forked by the kernel for
 	  every uevent.
 
+config DEVTMPFS
+	bool "Create a kernel maintained /dev tmpfs (EXPERIMENTAL)"
+	depends on HOTPLUG
+	help
+	  This creates a tmpfs filesystem, and mounts it at bootup
+	  and mounts it at /dev. The kernel driver core creates device
+	  nodes for all registered devices in that filesystem. All device
+	  nodes are owned by root and have the default mode of 0600.
+	  Userspace can add and delete the nodes as needed. This is
+	  intended to simplify bootup, and make it possible to delay
+	  the initial coldplug at bootup done by udev in userspace.
+	  It should also provide a simpler way for rescue systems
+	  to bring up a kernel with dynamic major/minor numbers.
+	  Meaningful symlinks, permissions and device ownership must
+	  still be handled by userspace.
+	  If unsure, say N here.
+
+config DEVTMPFS_MOUNT
+	bool "Automount devtmpfs at /dev"
+	depends on DEVTMPFS
+	help
+	  This will mount devtmpfs at /dev if the kernel mounts the root
+	  filesystem. It will not affect initramfs based mounting.
+	  If unsure, say N here.
+
 config STANDALONE
 	bool "Select only drivers that don't need compile-time external firmware" if EXPERIMENTAL
 	default y
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -4,6 +4,7 @@ obj-y			:= core.o sys.o bus.o dd.o \
 			   driver.o class.o platform.o \
 			   cpu.o firmware.o init.o map.o devres.o \
 			   attribute_container.o transport_class.o
+obj-$(CONFIG_DEVTMPFS)	+= devtmpfs.o
 obj-y			+= power/
 obj-$(CONFIG_HAS_DMA)	+= dma-mapping.o
 obj-$(CONFIG_ISA)	+= isa.o
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -134,3 +134,9 @@ static inline void module_add_driver(str
 				     struct device_driver *drv) { }
 static inline void module_remove_driver(struct device_driver *drv) { }
 #endif
+
+#ifdef CONFIG_DEVTMPFS
+extern int devtmpfs_init(void);
+#else
+static inline int devtmpfs_init(void) { return 0; }
+#endif
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -920,6 +920,8 @@ int device_add(struct device *dev)
 		error = device_create_sys_dev_entry(dev);
 		if (error)
 			goto devtattrError;
+
+		devtmpfs_create_node(dev);
 	}
 
 	error = device_add_class_symlinks(dev);
@@ -1063,6 +1065,7 @@ void device_del(struct device *dev)
 	if (parent)
 		klist_del(&dev->p->knode_parent);
 	if (MAJOR(dev->devt)) {
+		devtmpfs_delete_node(dev);
 		device_remove_sys_dev_entry(dev);
 		device_remove_file(dev, &devt_attr);
 	}
--- /dev/null
+++ b/drivers/base/devtmpfs.c
@@ -0,0 +1,405 @@
+/*
+ * devtmpfs - tmpfs based device node filesystem
+ *
+ * Copyright (C) 2009, Kay Sievers <kay.sievers@vrfy.org>
+ *
+ * During bootup, before any driver core device is registered, a tmpfs
+ * filesystem is created. Every device which requests a devno, will
+ * create a device node in this filesystem. The node is named after the
+ * the nameof the device, or the susbsytem can provide a custom name
+ * for the node.
+ *
+ * All devices are owned by root. This is intended to simplify bootup, and
+ * make it possible to delay the initial coldplug done by udev in userspace.
+ *
+ * It should also provide a simpler way for rescue systems to bring up a
+ * kernel with dynamic major/minor numbers.
+ */
+
+#include <linux/kernel.h>
+#include <linux/syscalls.h>
+#include <linux/mount.h>
+#include <linux/device.h>
+#include <linux/genhd.h>
+#include <linux/namei.h>
+#include <linux/fs.h>
+#include <linux/cred.h>
+
+static DECLARE_MUTEX(dev_sb_sem);
+static struct vfsmount *dev_mnt;
+static struct file_system_type dev_fs_type;
+static struct cred *kern_cred;
+
+#if defined CONFIG_DEVTMPFS_MOUNT
+static int dev_mount = 1;
+#else
+static int dev_mount;
+#endif
+
+static int __init mount_param(char *str)
+{
+	dev_mount = simple_strtoul(str, NULL, 0);
+	return 1;
+}
+__setup("devtmpfs.mount=", mount_param);
+
+static int dev_get_sb(struct file_system_type *fs_type, int flags,
+		      const char *dev_name, void *data, struct vfsmount *mnt)
+{
+	int ret = 0;
+
+	down(&dev_sb_sem);
+	if (!dev_mnt) {
+		static struct file_system_type *tmpfs;
+
+		tmpfs = get_fs_type("tmpfs");
+		if (!tmpfs) {
+			printk(KERN_ERR "dev_get_sb: unable get tmpfs "
+			       "fstype\n");
+			ret = -ENOENT;
+			goto out;
+		}
+		ret = tmpfs->get_sb(fs_type, flags, dev_name, data, mnt);
+		if (ret) {
+			printk(KERN_ERR "dev_get_sb: unable to init "
+			       "tmpfs superblock\n");
+			goto out;
+		}
+		dev_mnt = mnt;
+	} else {
+		/* we use a tmpfs superblock, fill_super() is not called */
+		get_sb_single(fs_type, flags, data, NULL, mnt);
+	}
+out:
+	up(&dev_sb_sem);
+	return ret;
+}
+
+static struct file_system_type dev_fs_type = {
+	.name = "devtmpfs",
+	.get_sb = dev_get_sb,
+	.kill_sb = kill_litter_super,
+};
+
+#ifdef CONFIG_BLOCK
+static inline int is_blockdev(struct device *dev)
+{
+	return dev->class == &block_class;
+}
+#else
+static inline int is_blockdev(struct device *dev) { return 0; }
+#endif
+
+static int dev_mkdir(const char *name, mode_t mode)
+{
+	struct nameidata nd;
+	struct dentry *dentry;
+	int err;
+
+	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+			      name, LOOKUP_PARENT, &nd);
+	if (err)
+		return err;
+
+	dentry = lookup_create(&nd, 1);
+	if (!IS_ERR(dentry)) {
+		err = vfs_mkdir(nd.path.dentry->d_inode, dentry, mode);
+		dput(dentry);
+	} else {
+		err = PTR_ERR(dentry);
+	}
+	mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
+
+	path_put(&nd.path);
+	return err;
+}
+
+static int create_path(const char *nodepath)
+{
+	char *path;
+	struct nameidata nd;
+	int err = 0;
+
+	path = kstrdup(nodepath, GFP_KERNEL);
+	if (!path)
+		return -ENOMEM;
+
+	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+			      path, LOOKUP_PARENT, &nd);
+	if (err == 0) {
+		struct dentry *dentry;
+
+		/* create directory right away */
+		dentry = lookup_create(&nd, 1);
+		if (!IS_ERR(dentry)) {
+			err = vfs_mkdir(nd.path.dentry->d_inode,
+					dentry, 0775);
+			dput(dentry);
+		}
+		mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
+
+		path_put(&nd.path);
+	} else if (err == -ENOENT) {
+		char *s;
+
+		/* parent directories do not exist, create them */
+		s = path;
+		while (1) {
+			s = strchr(s, '/');
+			if (!s)
+				break;
+			s[0] = '\0';
+			err = dev_mkdir(path, 0755);
+			if (err && err != -EEXIST)
+				break;
+			s[0] = '/';
+			s++;
+		}
+	}
+
+	kfree(path);
+	return err;
+}
+
+int devtmpfs_create_node(struct device *dev)
+{
+	const char *tmp = NULL;
+	const char *nodename;
+	mode_t mode;
+	struct nameidata nd;
+	struct dentry *dentry;
+	int err;
+
+	if (!dev_mnt)
+		return 0;
+
+	nodename = device_get_nodename(dev, &tmp);
+	if (!nodename)
+		return -ENOMEM;
+
+	if (is_blockdev(dev))
+		mode = S_IFBLK|0600;
+	else
+		mode = S_IFCHR|0600;
+
+	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+			      nodename, LOOKUP_PARENT, &nd);
+	if (err == -ENOENT) {
+		/* create missing parent directories */
+		create_path(nodename);
+		err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+				      nodename, LOOKUP_PARENT, &nd);
+		if (err)
+			goto out_name;
+	}
+
+	dentry = lookup_create(&nd, 0);
+	if (!IS_ERR(dentry)) {
+		const struct cred *curr_cred;
+
+		curr_cred = override_creds(kern_cred);
+		err = vfs_mknod(nd.path.dentry->d_inode,
+				dentry, mode, dev->devt);
+		revert_creds(curr_cred);
+		/* mark as kernel created inode */
+		if (!err)
+			dentry->d_inode->i_private = &dev_mnt;
+		dput(dentry);
+	} else {
+		err = PTR_ERR(dentry);
+	}
+	mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
+
+	path_put(&nd.path);
+out_name:
+	kfree(tmp);
+	return err;
+}
+
+static int dev_rmdir(const char *name)
+{
+	struct nameidata nd;
+	struct dentry *dentry;
+	int err;
+
+	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+			      name, LOOKUP_PARENT, &nd);
+	if (err)
+		return err;
+
+	mutex_lock_nested(&nd.path.dentry->d_inode->i_mutex, I_MUTEX_PARENT);
+	dentry = lookup_one_len(nd.last.name, nd.path.dentry, nd.last.len);
+	if (!IS_ERR(dentry)) {
+		if (dentry->d_inode)
+			err = vfs_rmdir(nd.path.dentry->d_inode, dentry);
+		else
+			err = -ENOENT;
+		dput(dentry);
+	} else {
+		err = PTR_ERR(dentry);
+	}
+	mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
+
+	path_put(&nd.path);
+	return err;
+}
+
+static int delete_path(const char *nodepath)
+{
+	const char *path;
+	int err = 0;
+
+	path = kstrdup(nodepath, GFP_KERNEL);
+	if (!path)
+		return -ENOMEM;
+
+	while (1) {
+		char *base;
+
+		base = strrchr(path, '/');
+		if (!base)
+			break;
+		base[0] = '\0';
+		err = dev_rmdir(path);
+		if (err)
+			break;
+	}
+
+	kfree(path);
+	return err;
+}
+
+static int dev_mynode(struct device *dev, struct inode *inode, struct kstat *stat)
+{
+	/* did we create it */
+	if (inode->i_private != &dev_mnt)
+		return 0;
+
+	/* does the dev_t match */
+	if (is_blockdev(dev)) {
+		if (!S_ISBLK(stat->mode))
+			return 0;
+	} else {
+		if (!S_ISCHR(stat->mode))
+			return 0;
+	}
+	if (stat->rdev != dev->devt)
+		return 0;
+
+	/* ours */
+	return 1;
+}
+
+int devtmpfs_delete_node(struct device *dev)
+{
+	const char *tmp = NULL;
+	const char *nodename;
+	struct nameidata nd;
+	struct dentry *dentry;
+	struct kstat stat;
+	int deleted = 1;
+	int err;
+
+	if (!dev_mnt)
+		return 0;
+
+	nodename = device_get_nodename(dev, &tmp);
+	if (!nodename)
+		return -ENOMEM;
+
+	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+			      nodename, LOOKUP_PARENT, &nd);
+	if (err)
+		goto out_name;
+
+	mutex_lock_nested(&nd.path.dentry->d_inode->i_mutex, I_MUTEX_PARENT);
+	dentry = lookup_one_len(nd.last.name, nd.path.dentry, nd.last.len);
+	if (!IS_ERR(dentry)) {
+		if (dentry->d_inode) {
+			err = vfs_getattr(nd.path.mnt, dentry, &stat);
+			if (!err && dev_mynode(dev, dentry->d_inode, &stat)) {
+				err = vfs_unlink(nd.path.dentry->d_inode,
+						 dentry);
+				if (!err || err == -ENOENT)
+					deleted = 1;
+			}
+		} else {
+			err = -ENOENT;
+		}
+		dput(dentry);
+	} else {
+		err = PTR_ERR(dentry);
+	}
+	mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
+
+	path_put(&nd.path);
+	if (deleted && strchr(nodename, '/'))
+		delete_path(nodename);
+out_name:
+	kfree(tmp);
+	return err;
+}
+
+/* After the root filesystem is mounted by the kernel at /root, or the
+ * initramfs in extracted at /root, this tmpfs will be mounted at /root/dev.
+ */
+int devtmpfs_mount(const char *mountpoint)
+{
+	struct path path;
+	int err;
+
+	if (!dev_mount)
+		return 0;
+
+	if (!dev_mnt)
+		return 0;
+
+	err = kern_path(mountpoint, LOOKUP_FOLLOW, &path);
+	if (err)
+		return err;
+	err = do_add_mount(dev_mnt, &path, 0, NULL);
+	if (err)
+		printk(KERN_INFO "devtmpfs: error mounting %i\n", err);
+	else
+		printk(KERN_INFO "devtmpfs: mounted\n");
+	path_put(&path);
+	return err;
+}
+
+/*
+ * Create tmpfs mount, created core devices will add their device device
+ * nodes here.
+ */
+int __init devtmpfs_init(void)
+{
+	int err;
+	struct vfsmount *mnt;
+
+	kern_cred = prepare_kernel_cred(NULL);
+	if (!kern_cred) {
+		printk(KERN_ERR "devtmpfs: unable to create credentials\n");
+		return -EINVAL;
+	}
+
+	err = register_filesystem(&dev_fs_type);
+	if (err) {
+		printk(KERN_ERR "devtmpfs: unable to register devtmpfs "
+		       "type %i\n", err);
+		put_cred(kern_cred);
+		return err;
+	}
+
+	mnt = kern_mount(&dev_fs_type);
+	if (IS_ERR(mnt)) {
+		err = PTR_ERR(mnt);
+		printk(KERN_ERR "devtmpfs: unable to create devtmpfs %i\n", err);
+		unregister_filesystem(&dev_fs_type);
+		put_cred(kern_cred);
+		return err;
+	}
+
+	dev_mkdir("shm", 01755);
+
+	printk(KERN_INFO "devtmpfs: initialized\n");
+	return 0;
+}
--- a/drivers/base/init.c
+++ b/drivers/base/init.c
@@ -20,6 +20,7 @@
 void __init driver_init(void)
 {
 	/* These are the core pieces */
+	devtmpfs_init();
 	devices_init();
 	buses_init();
 	classes_init();
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -553,6 +553,16 @@ extern void put_device(struct device *de
 
 extern void wait_for_device_probe(void);
 
+#ifdef CONFIG_DEVTMPFS
+extern int devtmpfs_create_node(struct device *dev);
+extern int devtmpfs_delete_node(struct device *dev);
+extern int devtmpfs_mount(const char *mountpoint);
+#else
+static inline int devtmpfs_create_node(struct device *dev) { return 0; }
+static inline int devtmpfs_delete_node(struct device *dev) { return 0; }
+static inline int devtmpfs_mount(const char *mountpoint) { return 0; }
+#endif
+
 /* drivers/base/power/shutdown.c */
 extern void device_shutdown(void);
 
--- a/include/linux/shmem_fs.h
+++ b/include/linux/shmem_fs.h
@@ -42,6 +42,8 @@ static inline struct shmem_inode_info *S
 	return container_of(inode, struct shmem_inode_info, vfs_inode);
 }
 
+extern int init_tmpfs(void);
+
 #ifdef CONFIG_TMPFS_POSIX_ACL
 int shmem_permission(struct inode *, int);
 int shmem_acl_init(struct inode *, struct inode *);
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -414,7 +414,7 @@ void __init prepare_namespace(void)
 
 	mount_root();
 out:
+	devtmpfs_mount("dev");
 	sys_mount(".", "/", NULL, MS_MOVE, NULL);
 	sys_chroot(".");
 }
-
--- a/init/main.c
+++ b/init/main.c
@@ -64,6 +64,7 @@
 #include <linux/idr.h>
 #include <linux/ftrace.h>
 #include <linux/async.h>
+#include <linux/shmem_fs.h>
 #include <trace/boot.h>
 
 #include <asm/io.h>
@@ -778,6 +779,7 @@ static void __init do_basic_setup(void)
 	init_workqueues();
 	cpuset_init_smp();
 	usermodehelper_init();
+	init_tmpfs();
 	driver_init();
 	init_irq_proc();
 	do_initcalls();
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2523,7 +2523,7 @@ static struct file_system_type tmpfs_fs_
 	.kill_sb	= kill_litter_super,
 };
 
-static int __init init_tmpfs(void)
+int __init init_tmpfs(void)
 {
 	int error;
 
@@ -2580,7 +2580,7 @@ static struct file_system_type tmpfs_fs_
 	.kill_sb	= kill_litter_super,
 };
 
-static int __init init_tmpfs(void)
+int __init init_tmpfs(void)
 {
 	BUG_ON(register_filesystem(&tmpfs_fs_type) != 0);
 
@@ -2691,5 +2691,3 @@ int shmem_zero_setup(struct vm_area_stru
 	vma->vm_ops = &shmem_vm_ops;
 	return 0;
 }
-
-module_init(init_tmpfs)

Re: [patch 00/13] devtmpfs patches

[David P. Quigley]

Does this apply to a vanilla tree or is this on top of your original
patch set?

Dave

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Wed, May 13, 2009 at 01:22, David P. Quigley <dpquigl@tycho.nsa.gov> wrote:
> Does this apply to a vanilla tree or is this on top of your original
> patch set?

It updates the one in Greg's tree, which is on top of current Linus'
git. It does no longer auto-mount devtmpfs in the initramfs, only for
kernel-mounts, if told to do. So the original issue might no longer be
visible, unless it is mounted there, or the one line call, that did
the auto-mount is restored.

Here is the patch in Greg's tree:
  http://git.kernel.org/?p=linux/kernel/git/gregkh/patches.git;a=blob;f=driver-core/driver-core-devtmpfs-driver-core-maintained-dev-tmpfs.patch;hb=HEAD

Thanks,
Kay

Re: [patch 00/13] devtmpfs patches

[Greg KH]

On Wed, May 13, 2009 at 01:34:13AM +0200, Kay Sievers wrote:
> On Wed, May 13, 2009 at 01:22, David P. Quigley <dpquigl@tycho.nsa.gov> wrote:
> > Does this apply to a vanilla tree or is this on top of your original
> > patch set?
> 
> It updates the one in Greg's tree, which is on top of current Linus'
> git. It does no longer auto-mount devtmpfs in the initramfs, only for
> kernel-mounts, if told to do. So the original issue might no longer be
> visible, unless it is mounted there, or the one line call, that did
> the auto-mount is restored.
> 
> Here is the patch in Greg's tree:
>   http://git.kernel.org/?p=linux/kernel/git/gregkh/patches.git;a=blob;f=driver-core/driver-core-devtmpfs-driver-core-maintained-dev-tmpfs.patch;hb=HEAD

I'll replace this version, with your new one, so people can test with
linux-next easier tomorrow.

thanks,

greg k-h

Re: [patch 00/13] devtmpfs patches

[Stephen Smalley]

On Wed, 2009-05-13 at 00:55 +0200, Kay Sievers wrote:
> On Tue, 2009-05-12 at 17:54 +0200, Kay Sievers wrote:
> > On Tue, May 12, 2009 at 17:35, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > 
> > > I think the issue is that the devtmpfs functions are calling vfs helpers
> > > to create and unlink the device nodes, and those helpers apply
> > > permission checks based on the current process' credentials.  I think a
> > > similar issue arose in sysfs a while ago.  Options are to either bypass
> > > the vfs helpers to avoid that permission checking for what I think are
> > > intended to be kernel-internal operations, or to override credentials
> > > temporarily around the calls to the vfs helpers, ala:
> > > new_cred = prepare_kernel_cred(NULL);
> > > old_cred  = override_creds(new_cred);
> > > rc = vfs_mknod(...);
> > > revert_creds(old_cred);
> > 
> > Ah, I see.
> 
> Here is the current state of the patch. It would be great, if you can
> have a quick look, if that matches what you meant. It runs fine here,
> but I didn't try any security enforcing software so far, which might run
> into trouble without the credential stuff.

I think you'll actually need to switch credentials around the entire
sequence starting from vfs_path_lookup() and going through the
vfs_mknod() call in order to avoid any denials from vfs_path_lookup,
vfs_mkdir (via create_path), and vfs_mknod.

Then the same issue applies to devtmpfs_delete_node() to prevent unlink
denials against the current process when a node is removed, similarly
wrapping everything from the vfs_path_lookup() through the final
delete_path() call.

-- 
Stephen Smalley
National Security Agency

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Wed, May 13, 2009 at 14:22, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> I think you'll actually need to switch credentials around the entire
> sequence starting from vfs_path_lookup() and going through the
> vfs_mknod() call in order to avoid any denials from vfs_path_lookup,
> vfs_mkdir (via create_path), and vfs_mknod.
>
> Then the same issue applies to devtmpfs_delete_node() to prevent unlink
> denials against the current process when a node is removed, similarly
> wrapping everything from the vfs_path_lookup() through the final
> delete_path() call.

Ok, good, will do that. Anything like this to keep in mind when
creating/removing simple subdirectories?

Thanks,
Kay

Re: [patch 00/13] devtmpfs patches

[Stephen Smalley]

On Wed, 2009-05-13 at 14:58 +0200, Kay Sievers wrote:
> On Wed, May 13, 2009 at 14:22, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
> > I think you'll actually need to switch credentials around the entire
> > sequence starting from vfs_path_lookup() and going through the
> > vfs_mknod() call in order to avoid any denials from vfs_path_lookup,
> > vfs_mkdir (via create_path), and vfs_mknod.
> >
> > Then the same issue applies to devtmpfs_delete_node() to prevent unlink
> > denials against the current process when a node is removed, similarly
> > wrapping everything from the vfs_path_lookup() through the final
> > delete_path() call.
> 
> Ok, good, will do that. Anything like this to keep in mind when
> creating/removing simple subdirectories?

Yes, any time you call any vfs helper (and thus are subject to the
permission checking calls, both DAC and LSM/SELinux), you need to decide
whether you truly want those permission checks to get applied against
the current process' credentials or whether you should be using
alternate credentials for the call.  If on the other hand you can
perform your operations at a lower level (e.g. direct calls to the
underlying inode operations), then you don't have to be concerned with
the permission checking, but there is still the issue of ownership and
file security labeling for any new files/directories you create, so even
there you may need to establish different credentials to avoid
unwittingly creating those files with the uid/security context of
whatever the current process happens to be.

-- 
Stephen Smalley
National Security Agency

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Wed, May 13, 2009 at 14:57, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> Ok, good, will do that. Anything like this to keep in mind when
>> creating/removing simple subdirectories?
>
> Yes, any time you call any vfs helper (and thus are subject to the
> permission checking calls, both DAC and LSM/SELinux), you need to decide
> whether you truly want those permission checks to get applied against
> the current process' credentials or whether you should be using
> alternate credentials for the call.

Yeah, I see. I'll wrap the entire operation in the swapped
credentials, which should be the best option anyway.

Thanks a lot,
Kay

Re: [patch 00/13] devtmpfs patches

[Alan Cox]

Had a poke at the crash - seems to be a devtmpfs bug at the moment.

Re: [patch 00/13] devtmpfs patches

[David Howells]

Kay Sievers <kay.sievers@vrfy.org> wrote:

> +static struct cred *kern_cred;

Can I suggest that you call your cred pointer dev_cred rather than kern_cred
so that the naming is consistent with the other globals variables?

> +	kern_cred = prepare_kernel_cred(NULL);

If you have no intention of altering the credentials you create, you might
want to use &init_cred instead of kern_cred.  That said, you might want to
allocate it and let the security module alter it before you use it.

Also, Stephen is right, you should probably wrap all your accesses to the VFS
in your devtmpfs credentials.  For instance, devtmpfs_create_node() calls
vfs_mkdir() with the process's credentials via create_path() and directly with
the kern_cred.

What you probably want is:

	int devtmpfs_create_node(struct device *dev)
	{
		const struct cred *curr_cred;
		const char *tmp = NULL;
		const char *nodename;
		mode_t mode;
		struct nameidata nd;
		struct dentry *dentry;
		int err;

		if (!dev_mnt)
			return 0;

		nodename = device_get_nodename(dev, &tmp);
		if (!nodename)
			return -ENOMEM;

		curr_cred = override_creds(kern_cred);

		if (is_blockdev(dev))
			mode = S_IFBLK|0600;
		else
			mode = S_IFCHR|0600;

		err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
				      nodename, LOOKUP_PARENT, &nd);
		if (err == -ENOENT) {
			/* create missing parent directories */
			create_path(nodename);
			err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
					      nodename, LOOKUP_PARENT, &nd);
			if (err)
				goto out_name;
		}

		dentry = lookup_create(&nd, 0);
		if (!IS_ERR(dentry)) {
			err = vfs_mknod(nd.path.dentry->d_inode,
					dentry, mode, dev->devt);
			/* mark as kernel created inode */
			if (!err)
				dentry->d_inode->i_private = &dev_mnt;
			dput(dentry);
		} else {
			err = PTR_ERR(dentry);
		}
		mutex_unlock(&nd.path.dentry->d_inode->i_mutex);

		path_put(&nd.path);
	out_name:
		revert_creds(curr_cred);
		kfree(tmp);
		return err;
	}

David

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Wed, May 13, 2009 at 15:20, David Howells <dhowells@redhat.com> wrote:
> Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> +static struct cred *kern_cred;
>
> Can I suggest that you call your cred pointer dev_cred rather than kern_cred
> so that the naming is consistent with the other globals variables?

Sounds good.

>> +     kern_cred = prepare_kernel_cred(NULL);
>
> If you have no intention of altering the credentials you create, you might
> want to use &init_cred instead of kern_cred.  That said, you might want to
> allocate it and let the security module alter it before you use it.

Ah, didn't know that it was exported. It's the one in
include/linux/init_task.h, right? I'll give that a try.

> Also, Stephen is right, you should probably wrap all your accesses to the VFS
> in your devtmpfs credentials.  For instance, devtmpfs_create_node() calls
> vfs_mkdir() with the process's credentials via create_path() and directly with
> the kern_cred.
>
> What you probably want is:

>               nodename = device_get_nodename(dev, &tmp);
>               if (!nodename)
>                      return -ENOMEM;
>                curr_cred = override_creds(kern_cred);
...
>        out_name:
>                revert_creds(curr_cred);

Yeah, I have exactly that already now.

Thanks,
Kay

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Wed, May 13, 2009 at 15:34, Kay Sievers <kay.sievers@vrfy.org> wrote:

>>> +     kern_cred = prepare_kernel_cred(NULL);
>>
>> If you have no intention of altering the credentials you create, you might
>> want to use &init_cred instead of kern_cred.  That said, you might want to
>> allocate it and let the security module alter it before you use it.
>
> Ah, didn't know that it was exported. It's the one in
> include/linux/init_task.h, right? I'll give that a try.

That seems to work fine here. Thanks a lot for the help.

Maybe we could do the same credential swap in sysfs, and get rid of:
/**
 * lookup_one_noperm - bad hack for sysfs
 * @name:       pathname component to lookup
 * @base:       base directory to lookup from
 *
 * This is a variant of lookup_one_len that doesn't perform any permission
 * checks.   It's a horrible hack to work around the braindead sysfs
 * architecture and should not be used anywhere else.
 *
 * DON'T USE THIS FUNCTION EVER, thanks.
 */

in fs/namei.c?

Seems a bit odd to have a vfs function for a single filesystem, called
from a single location, and annotated as "do not use". Christoph added
the comment a while ago, so adding him to Cc:.

Thanks,
Kay

Re: [patch 00/13] devtmpfs patches

[Stephen Smalley]

On Wed, 2009-05-13 at 16:20 +0200, Kay Sievers wrote:
> On Wed, May 13, 2009 at 15:34, Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> >>> +     kern_cred = prepare_kernel_cred(NULL);
> >>
> >> If you have no intention of altering the credentials you create, you might
> >> want to use &init_cred instead of kern_cred.  That said, you might want to
> >> allocate it and let the security module alter it before you use it.
> >
> > Ah, didn't know that it was exported. It's the one in
> > include/linux/init_task.h, right? I'll give that a try.
> 
> That seems to work fine here. Thanks a lot for the help.
> 
> Maybe we could do the same credential swap in sysfs, and get rid of:
> /**
>  * lookup_one_noperm - bad hack for sysfs
>  * @name:       pathname component to lookup
>  * @base:       base directory to lookup from
>  *
>  * This is a variant of lookup_one_len that doesn't perform any permission
>  * checks.   It's a horrible hack to work around the braindead sysfs
>  * architecture and should not be used anywhere else.
>  *
>  * DON'T USE THIS FUNCTION EVER, thanks.
>  */
> 
> in fs/namei.c?
> 
> Seems a bit odd to have a vfs function for a single filesystem, called
> from a single location, and annotated as "do not use". Christoph added
> the comment a while ago, so adding him to Cc:.

Yes, that makes sense to me as well - we didn't have the credentials
infrastructure in place at the time that lookup_one_noperm was
introduced, but switching the credentials around a normal lookup_one_len
call should work now.

-- 
Stephen Smalley
National Security Agency

Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Wed, 2009-05-13 at 10:35 -0400, Stephen Smalley wrote:
> > Maybe we could do the same credential swap in sysfs, and get rid of:
> > /**
> >  * lookup_one_noperm - bad hack for sysfs
> > 
> > Seems a bit odd to have a vfs function for a single filesystem, called
> > from a single location, and annotated as "do not use". Christoph added
> > the comment a while ago, so adding him to Cc:.
> 
> Yes, that makes sense to me as well - we didn't have the credentials
> infrastructure in place at the time that lookup_one_noperm was
> introduced, but switching the credentials around a normal lookup_one_len
> call should work now.

Something like this? It seems to work fine here, but I did not test it with SELinux.

Thanks,
Kay


From: Kay Sievers <kay.sievers@vrfy.org>
Subject: sysfs - switch noperm lookup_one_len() hack to credentials switch
Cc: Greg KH <greg@kroah.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: David Howells <dhowells@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>

Driver core actions may be requested by processes, which do not have the
proper permissions in a DAC and LSM/SELinux context to create entries in
sysfs. This replaces the vfs noperm hack with a switch to init_cred before
sysfs entries are created.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
---
 fs/namei.c            |   22 ----------------------
 fs/sysfs/dir.c        |    7 ++++++-
 include/linux/namei.h |    1 -
 3 files changed, 6 insertions(+), 24 deletions(-)

--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1260,28 +1260,6 @@ struct dentry *lookup_one_len(const char
 	return __lookup_hash(&this, base, NULL);
 }
 
-/**
- * lookup_one_noperm - bad hack for sysfs
- * @name:	pathname component to lookup
- * @base:	base directory to lookup from
- *
- * This is a variant of lookup_one_len that doesn't perform any permission
- * checks.   It's a horrible hack to work around the braindead sysfs
- * architecture and should not be used anywhere else.
- *
- * DON'T USE THIS FUNCTION EVER, thanks.
- */
-struct dentry *lookup_one_noperm(const char *name, struct dentry *base)
-{
-	int err;
-	struct qstr this;
-
-	err = __lookup_one_len(name, &this, base, strlen(name));
-	if (err)
-		return ERR_PTR(err);
-	return __lookup_hash(&this, base, NULL);
-}
-
 int user_path_at(int dfd, const char __user *name, unsigned flags,
 		 struct path *path)
 {
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -21,6 +21,8 @@
 #include <linux/completion.h>
 #include <linux/mutex.h>
 #include <linux/slab.h>
+#include <linux/cred.h>
+#include <linux/init_task.h>
 #include "sysfs.h"
 
 DEFINE_MUTEX(sysfs_mutex);
@@ -103,6 +105,7 @@ struct dentry *sysfs_get_dentry(struct s
 
 	while (dentry->d_fsdata != sd) {
 		struct sysfs_dirent *cur;
+		const struct cred *curr_cred;
 		struct dentry *parent;
 
 		/* find the first ancestor which hasn't been looked up */
@@ -111,11 +114,13 @@ struct dentry *sysfs_get_dentry(struct s
 			cur = cur->s_parent;
 
 		/* look it up */
+		curr_cred = override_creds(&init_cred);
 		parent = dentry;
 		mutex_lock(&parent->d_inode->i_mutex);
-		dentry = lookup_one_noperm(cur->s_name, parent);
+		dentry = lookup_one_len(cur->s_name, parent, strlen(cur->s_name));
 		mutex_unlock(&parent->d_inode->i_mutex);
 		dput(parent);
+		revert_creds(curr_cred);
 
 		if (IS_ERR(dentry))
 			break;
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -75,7 +75,6 @@ extern struct file *nameidata_to_filp(st
 extern void release_open_intent(struct nameidata *);
 
 extern struct dentry *lookup_one_len(const char *, struct dentry *, int);
-extern struct dentry *lookup_one_noperm(const char *, struct dentry *);
 
 extern int follow_down(struct vfsmount **, struct dentry **);
 extern int follow_up(struct vfsmount **, struct dentry **);

Re: [patch 00/13] devtmpfs patches

[Eric W. Biederman]

Kay Sievers <kay.sievers@vrfy.org> writes:

> On Wed, 2009-05-13 at 10:35 -0400, Stephen Smalley wrote:
>> > Maybe we could do the same credential swap in sysfs, and get rid of:
>> > /**
>> >  * lookup_one_noperm - bad hack for sysfs
>> > 
>> > Seems a bit odd to have a vfs function for a single filesystem, called
>> > from a single location, and annotated as "do not use". Christoph added
>> > the comment a while ago, so adding him to Cc:.
>> 
>> Yes, that makes sense to me as well - we didn't have the credentials
>> infrastructure in place at the time that lookup_one_noperm was
>> introduced, but switching the credentials around a normal lookup_one_len
>> call should work now.
>
> Something like this? It seems to work fine here, but I did not test it with SELinux.

That just masks the problem not fixes it.

The problem is that sysfs attempts to keep the dcache in lock-step with
the sysfs_dentries.

The VFS model is lazy coherency and bringing things in sync on access.
This is important to avoid locking problems.

Eric

Re: [patch 00/13] devtmpfs patches

[Greg KH]

On Wed, May 13, 2009 at 03:43:28PM -0700, Eric W. Biederman wrote:
> Kay Sievers <kay.sievers@vrfy.org> writes:
> 
> > On Wed, 2009-05-13 at 10:35 -0400, Stephen Smalley wrote:
> >> > Maybe we could do the same credential swap in sysfs, and get rid of:
> >> > /**
> >> >  * lookup_one_noperm - bad hack for sysfs
> >> > 
> >> > Seems a bit odd to have a vfs function for a single filesystem, called
> >> > from a single location, and annotated as "do not use". Christoph added
> >> > the comment a while ago, so adding him to Cc:.
> >> 
> >> Yes, that makes sense to me as well - we didn't have the credentials
> >> infrastructure in place at the time that lookup_one_noperm was
> >> introduced, but switching the credentials around a normal lookup_one_len
> >> call should work now.
> >
> > Something like this? It seems to work fine here, but I did not test it with SELinux.
> 
> That just masks the problem not fixes it.
> 
> The problem is that sysfs attempts to keep the dcache in lock-step with
> the sysfs_dentries.
> 
> The VFS model is lazy coherency and bringing things in sync on access.
> This is important to avoid locking problems.

So how would you propose to resolve this?

thanks,

greg k-h