Re: grey- and blacklisting drivers [Was: Re: Using the "best

Re: grey- and blacklisting drivers [Was: Re: Using the "best

[Pete Zaitcev]

On Wed, 7 Dec 2005 17:23:32 -0800, Greg KH <greg@kroah.com> wrote:

>  Would something like the libusual code in
> -mm work better for this instead?

I have suggested libusual but Pavel rejected it with ... this:

> From: Pavel Roskin <proski@gnu.org>
> To: Pete Zaitcev <zaitcev@redhat.com>
> Subject: Re: Using the "best available" driver
> Date: Sat, 03 Dec 2005 02:59:21 -0500

> I think the libusual approach doesn't scale and depends on the good will
> of the maintainers of the device drivers.

No comment necessary. :-)

-- Pete


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Jean Tourrilhes]

On Wed, Dec 07, 2005 at 06:15:24PM -0800, Pete Zaitcev wrote:
> On Wed, 7 Dec 2005 17:23:32 -0800, Greg KH <greg@kroah.com> wrote:
> 
> >  Would something like the libusual code in
> > -mm work better for this instead?
> 
> I have suggested libusual but Pavel rejected it with ... this:
> 
> > From: Pavel Roskin <proski@gnu.org>
> > To: Pete Zaitcev <zaitcev@redhat.com>
> > Subject: Re: Using the "best available" driver
> > Date: Sat, 03 Dec 2005 02:59:21 -0500
> 
> > I think the libusual approach doesn't scale and depends on the good will
> > of the maintainers of the device drivers.
> 
> No comment necessary. :-)
> 
> -- Pete

	Ok, I had a look at libusual. I'm sorry, but it won't work
with some of my scenario (having both a Prism2 and an Orinoco card
active at the same time).

	Moreover, I don't want to offend you, but I personally don't
really like the overall approach. You really want to keep drivers as a
self encapsualted entities, as independant as possible from each
other. This simplify maintainance and avoid breakage, and allow to add
or remove drivers from the kernel tree with minimal disruptions. This
approach also force you to unload drivers to change the bias, and is
very coarse grained (unless you change the libusual API).
	And it's not generic, you have to hack each driver, which is
kernel bloat, whereas this generic issue calls for a generic
solution. Potentially, over time, each libusual may develop it's own
specific extensions for added "features".
	The generic script from Dominik seems to offer a simpler
alternative, which doesn't require extensive changes. An user-space
override table keeps the spirit of "Policy in user space, not in the
kernel" (devfs vs. udev).
	But all my personal opinions don't really matter, as the
libusual simply doesn't support the required scenario.

	Have fun...

	Jean



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Kay Sievers]

On Wed, Dec 07, 2005 at 06:54:48PM -0800, Jean Tourrilhes wrote:
> On Wed, Dec 07, 2005 at 06:15:24PM -0800, Pete Zaitcev wrote:
> > On Wed, 7 Dec 2005 17:23:32 -0800, Greg KH <greg@kroah.com> wrote:
> > 
> > >  Would something like the libusual code in
> > > -mm work better for this instead?
> > 
> > I have suggested libusual but Pavel rejected it with ... this:
> > 
> > > From: Pavel Roskin <proski@gnu.org>
> > > To: Pete Zaitcev <zaitcev@redhat.com>
> > > Subject: Re: Using the "best available" driver
> > > Date: Sat, 03 Dec 2005 02:59:21 -0500
> > 
> > > I think the libusual approach doesn't scale and depends on the good will
> > > of the maintainers of the device drivers.
> > 
> > No comment necessary. :-)
> > 
> > -- Pete
> 
> 	Ok, I had a look at libusual. I'm sorry, but it won't work
> with some of my scenario (having both a Prism2 and an Orinoco card
> active at the same time).
> 
> 	Moreover, I don't want to offend you, but I personally don't
> really like the overall approach. You really want to keep drivers as a
> self encapsualted entities, as independant as possible from each
> other. This simplify maintainance and avoid breakage, and allow to add
> or remove drivers from the kernel tree with minimal disruptions. This
> approach also force you to unload drivers to change the bias, and is
> very coarse grained (unless you change the libusual API).
> 	And it's not generic, you have to hack each driver, which is
> kernel bloat, whereas this generic issue calls for a generic
> solution. Potentially, over time, each libusual may develop it's own
> specific extensions for added "features".
> 	The generic script from Dominik seems to offer a simpler
> alternative, which doesn't require extensive changes. An user-space
> override table keeps the spirit of "Policy in user space, not in the
> kernel" (devfs vs. udev).
> 	But all my personal opinions don't really matter, as the
> libusual simply doesn't support the required scenario.

Wouldn't it make the most sense to have a generic flag to pass to _any_
driver to skip the bus probing and wait for a manual bind? This would be
useful for the storage controllers too, that have 1000's of disks connected,
cause you don't really want to trigger all that buses at once with
a modprobe.

That way, you would just need to disable all autobinding with the module
configuration and depend on the bus device events to match a given
configuration to "manually" enable every device with the udev event.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Greg KH]

On Thu, Dec 08, 2005 at 04:31:45PM +0100, Kay Sievers wrote:
> On Wed, Dec 07, 2005 at 06:54:48PM -0800, Jean Tourrilhes wrote:
> > On Wed, Dec 07, 2005 at 06:15:24PM -0800, Pete Zaitcev wrote:
> > > On Wed, 7 Dec 2005 17:23:32 -0800, Greg KH <greg@kroah.com> wrote:
> > > 
> > > >  Would something like the libusual code in
> > > > -mm work better for this instead?
> > > 
> > > I have suggested libusual but Pavel rejected it with ... this:
> > > 
> > > > From: Pavel Roskin <proski@gnu.org>
> > > > To: Pete Zaitcev <zaitcev@redhat.com>
> > > > Subject: Re: Using the "best available" driver
> > > > Date: Sat, 03 Dec 2005 02:59:21 -0500
> > > 
> > > > I think the libusual approach doesn't scale and depends on the good will
> > > > of the maintainers of the device drivers.
> > > 
> > > No comment necessary. :-)
> > > 
> > > -- Pete
> > 
> > 	Ok, I had a look at libusual. I'm sorry, but it won't work
> > with some of my scenario (having both a Prism2 and an Orinoco card
> > active at the same time).
> > 
> > 	Moreover, I don't want to offend you, but I personally don't
> > really like the overall approach. You really want to keep drivers as a
> > self encapsualted entities, as independant as possible from each
> > other. This simplify maintainance and avoid breakage, and allow to add
> > or remove drivers from the kernel tree with minimal disruptions. This
> > approach also force you to unload drivers to change the bias, and is
> > very coarse grained (unless you change the libusual API).
> > 	And it's not generic, you have to hack each driver, which is
> > kernel bloat, whereas this generic issue calls for a generic
> > solution. Potentially, over time, each libusual may develop it's own
> > specific extensions for added "features".
> > 	The generic script from Dominik seems to offer a simpler
> > alternative, which doesn't require extensive changes. An user-space
> > override table keeps the spirit of "Policy in user space, not in the
> > kernel" (devfs vs. udev).
> > 	But all my personal opinions don't really matter, as the
> > libusual simply doesn't support the required scenario.
> 
> Wouldn't it make the most sense to have a generic flag to pass to _any_
> driver to skip the bus probing and wait for a manual bind? This would be
> useful for the storage controllers too, that have 1000's of disks connected,
> cause you don't really want to trigger all that buses at once with
> a modprobe.

Yes, that would be nice to have.

> That way, you would just need to disable all autobinding with the module
> configuration and depend on the bus device events to match a given
> configuration to "manually" enable every device with the udev event.

Crazy distro installer authors have suggested that we have a way to
disable all autobinding for a bus somehow, so they can do the binding
themselves.  They might not be so crazy after all :)

But as the codepaths for the "autobind" and the "manual bind" are almost
identical, it might be tough to disable the automatic stuff...

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Kay Sievers]

On Fri, Dec 09, 2005 at 08:20:41PM -0800, Greg KH wrote:
> On Thu, Dec 08, 2005 at 04:31:45PM +0100, Kay Sievers wrote:
> > Wouldn't it make the most sense to have a generic flag to pass to _any_
> > driver to skip the bus probing and wait for a manual bind? This would be
> > useful for the storage controllers too, that have 1000's of disks connected,
> > cause you don't really want to trigger all that buses at once with
> > a modprobe.
> 
> Yes, that would be nice to have.
> 
> > That way, you would just need to disable all autobinding with the module
> > configuration and depend on the bus device events to match a given
> > configuration to "manually" enable every device with the udev event.
> 
> Crazy distro installer authors have suggested that we have a way to
> disable all autobinding for a bus somehow, so they can do the binding
> themselves.  They might not be so crazy after all :)
> 
> But as the codepaths for the "autobind" and the "manual bind" are almost
> identical, it might be tough to disable the automatic stuff...

This quick hack works for me, but does it at the driver level, which is
nicer to use than a global bus control.

If the driver is already loaded, it can be controlled in sysfs or it can
be passed to modprobe and the driver gets initialized with that setting.
That way, modules/drivers can be set-up in modprobe.conf, to wait for
manual bind requests.

Thanks,
Kay

---
add "autobind" control to modules to specify device binding policy

This adds a sysfs control to every driver to control the automatic
binding of drivers to devices. If set to "0", the driver will only
bind devices if explicitely asked for, by using the "bind" file.

  $ tree /sys/bus/usb/drivers/ov511/
  /sys/bus/usb/drivers/ov511/
  |-- autobind
  |-- bind
  |-- module -> ../../../../module/ov511
  `-- unbind

At module load, "autobind=0" disables the automatic device bindung.
This is availabe to all current modules without changes.

  $ modprobe ov511
  $ cat /sys/bus/usb/drivers/ov511/autobind
  1

  $ rmmod ov511
  $ modprobe ov511 autobind=0
  $ cat /sys/bus/usb/drivers/ov511/autobind
  0

If a module implements the parameter "autobind" itself, the default
parameter is ignored.
---

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index fa601b0..946ac47 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -143,6 +143,18 @@ static int driver_helper(struct device *
 	return 0;
 }
 
+static ssize_t show_autobind(struct device_driver *drv, char *buf)
+{
+	return sprintf(buf, "%u\n",  (drv->autobind != 0));
+}
+static ssize_t store_autobind(struct device_driver *drv,
+			      const char *buf, size_t count)
+{
+	drv->autobind = (buf[0] != '0');
+	return count;
+}
+static DRIVER_ATTR(autobind, S_IRUSR | S_IWUSR, show_autobind, store_autobind);
+
 static ssize_t driver_unbind(struct device_driver *drv,
 			     const char *buf, size_t count)
 {
@@ -444,13 +456,15 @@ int bus_add_driver(struct device_driver 
 			return error;
 		}
 
-		driver_attach(drv);
+		if (drv->autobind)
+			driver_attach(drv);
 		klist_add_tail(&drv->knode_bus, &bus->klist_drivers);
 		module_add_driver(drv->owner, drv);
 
 		driver_add_attrs(bus, drv);
 		driver_create_file(drv, &driver_attr_unbind);
 		driver_create_file(drv, &driver_attr_bind);
+		driver_create_file(drv, &driver_attr_autobind);
 	}
 	return error;
 }
@@ -468,6 +482,7 @@ int bus_add_driver(struct device_driver 
 void bus_remove_driver(struct device_driver * drv)
 {
 	if (drv->bus) {
+		driver_remove_file(drv, &driver_attr_autobind);
 		driver_remove_file(drv, &driver_attr_bind);
 		driver_remove_file(drv, &driver_attr_unbind);
 		driver_remove_attrs(drv->bus, drv);
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 3b419c9..16312a9 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -110,6 +110,8 @@ int driver_probe_device(struct device_dr
 static int __device_attach(struct device_driver * drv, void * data)
 {
 	struct device * dev = data;
+	if (!drv->autobind)
+		return 0;
 	return driver_probe_device(drv, dev);
 }
 
diff --git a/drivers/base/driver.c b/drivers/base/driver.c
index 161f3a3..9982543 100644
--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@ -171,6 +171,10 @@ static void klist_devices_put(struct kli
  */
 int driver_register(struct device_driver * drv)
 {
+	if (drv->owner)
+		drv->autobind = drv->owner->autobind;
+	else
+		drv->autobind = 1;
 	klist_init(&drv->klist_devices, klist_devices_get, klist_devices_put);
 	init_completion(&drv->unloaded);
 	return bus_add_driver(drv);
diff --git a/include/linux/device.h b/include/linux/device.h
index 0cdee78..cb46422 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -98,6 +98,7 @@ struct device_driver {
 	struct klist_node	knode_bus;
 
 	struct module		* owner;
+	int			autobind;
 
 	int	(*probe)	(struct device * dev);
 	int	(*remove)	(struct device * dev);
diff --git a/include/linux/module.h b/include/linux/module.h
index 84d75f3..770429b 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -283,6 +283,9 @@ struct module
 	/* Am I GPL-compatible */
 	int license_gplok;
 
+	/* Drivers should bind at module init */
+	int autobind;
+
 #ifdef CONFIG_MODULE_UNLOAD
 	/* Reference counts */
 	struct module_ref ref[NR_CPUS];
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 368ec8e..676a9fd 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -96,7 +96,8 @@ extern int parse_args(const char *name,
 		      char *args,
 		      struct kernel_param *params,
 		      unsigned num,
-		      int (*unknown)(char *param, char *val));
+		      int (*unknown)(char *param, char *val, void *data),
+		      void *data);
 
 /* All the helper functions */
 /* The macros to do compile-time type checking stolen from Jakub
diff --git a/init/main.c b/init/main.c
index 27f97f9..3b871d3 100644
--- a/init/main.c
+++ b/init/main.c
@@ -224,7 +224,7 @@ __setup("loglevel=", loglevel);
  * Unknown boot options get handed to init, unless they look like
  * failed parameters
  */
-static int __init unknown_bootoption(char *param, char *val)
+static int __init unknown_bootoption(char *param, char *val, void *data)
 {
 	/* Change NUL term back to "=", to make "param" the whole string. */
 	if (val) {
@@ -408,7 +408,7 @@ static void noinline rest_init(void)
 } 
 
 /* Check for early params. */
-static int __init do_early_param(char *param, char *val)
+static int __init do_early_param(char *param, char *val, void *data)
 {
 	struct obs_kernel_param *p;
 
@@ -434,7 +434,8 @@ void __init parse_early_param(void)
 
 	/* All fall through to do_early_param. */
 	strlcpy(tmp_cmdline, saved_command_line, COMMAND_LINE_SIZE);
-	parse_args("early options", tmp_cmdline, NULL, 0, do_early_param);
+	parse_args("early options", tmp_cmdline, NULL, 0,
+		   do_early_param, NULL);
 	done = 1;
 }
 
@@ -480,7 +481,7 @@ asmlinkage void __init start_kernel(void
 	parse_early_param();
 	parse_args("Booting kernel", command_line, __start___param,
 		   __stop___param - __start___param,
-		   &unknown_bootoption);
+		   &unknown_bootoption, NULL);
 	sort_main_extable();
 	trap_init();
 	rcu_init();
diff --git a/kernel/module.c b/kernel/module.c
index 2ea929d..98ccc2a 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -842,7 +842,7 @@ static int obsolete_params(const char *n
 		kp[i].arg = &obsparm[i];
 	}
 
-	ret = parse_args(name, args, kp, num, NULL);
+	ret = parse_args(name, args, kp, num, NULL, NULL);
  out:
 	kfree(kp);
 	return ret;
@@ -1494,6 +1494,24 @@ static inline void add_kallsyms(struct m
 }
 #endif /* CONFIG_KALLSYMS */
 
+/* Catch given module paramters, not defined in the module itself */
+static int default_param(char *param, char *val, void *data)
+{
+	struct module *mod = data;
+
+	DEBUGP("default module param: param=%s, val=%s, data=%p\n",
+	       param, val, data);
+
+	if (!mod)
+		return -ENOENT;
+
+	if (strcmp(param, "autobind") = 0) {
+		mod->autobind = (val[0] != '0');
+		return 0;
+	}
+	return -ENOENT;
+}
+
 /* Allocate and load the module: note that size of section 0 is always
    zero, and we rely on this for optional sections. */
 static struct module *load_module(void __user *umod,
@@ -1799,6 +1817,7 @@ static struct module *load_module(void _
 			   (unsigned long)mod->module_core + mod->core_size);
 
 	set_fs(old_fs);
+	mod->autobind = 1;
 
 	mod->args = args;
 	if (obsparmindex) {
@@ -1820,7 +1839,7 @@ static struct module *load_module(void _
 				 sechdrs[setupindex].sh_addr,
 				 sechdrs[setupindex].sh_size
 				 / sizeof(struct kernel_param),
-				 NULL);
+				 default_param, mod);
 	}
 	if (err < 0)
 		goto arch_cleanup;
diff --git a/kernel/params.c b/kernel/params.c
index 47ba695..59f5b04 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -51,7 +51,8 @@ static int parse_one(char *param,
 		     char *val,
 		     struct kernel_param *params, 
 		     unsigned num_params,
-		     int (*handle_unknown)(char *param, char *val))
+		     int (*unknown)(char *param, char *val, void *data),
+		     void *data)
 {
 	unsigned int i;
 
@@ -64,9 +65,9 @@ static int parse_one(char *param,
 		}
 	}
 
-	if (handle_unknown) {
+	if (unknown) {
 		DEBUGP("Unknown argument: calling %p\n", handle_unknown);
-		return handle_unknown(param, val);
+		return unknown(param, val, data);
 	}
 
 	DEBUGP("Unknown argument `%s'\n", param);
@@ -132,7 +133,8 @@ int parse_args(const char *name,
 	       char *args,
 	       struct kernel_param *params,
 	       unsigned num,
-	       int (*unknown)(char *param, char *val))
+	       int (*unknown)(char *param, char *val, void *data),
+	       void *data)
 {
 	char *param, *val;
 
@@ -146,7 +148,7 @@ int parse_args(const char *name,
 		int ret;
 
 		args = next_arg(args, &param, &val);
-		ret = parse_one(param, val, params, num, unknown);
+		ret = parse_one(param, val, params, num, unknown, data);
 		switch (ret) {
 		case -ENOENT:
 			printk(KERN_ERR "%s: Unknown parameter `%s'\n",



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best

[Pavel Roskin]

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

> This quick hack works for me, but does it at the driver level, which is
> nicer to use than a global bus control.
>
> If the driver is already loaded, it can be controlled in sysfs or it can
> be passed to modprobe and the driver gets initialized with that setting.
> That way, modules/drivers can be set-up in modprobe.conf, to wait for
> manual bind requests.

Please, let's make "manual bind" independent of modules.  In fact, it's less
needed in case of modules, because you can control the order, in which they are
loaded.  When manual bind is really needed is the case of the monolithic kernel.

Every driver has a name, so we should be able to refer to it before it's loaded.
 There should be a way to tell the kernel not to autobind e.g. orinoco_cs,
whether it's a module or an in-kernel driver.  In the later case, we want some
kind of kernel command line support.

--
Regards,
Pavel Roskin


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Kay Sievers]

On Sun, Dec 11, 2005 at 10:48:56AM -0500, Pavel Roskin wrote:
> Quoting Kay Sievers <kay.sievers@vrfy.org>:
> 
> > This quick hack works for me, but does it at the driver level, which is
> > nicer to use than a global bus control.
> >
> > If the driver is already loaded, it can be controlled in sysfs or it can
> > be passed to modprobe and the driver gets initialized with that setting.
> > That way, modules/drivers can be set-up in modprobe.conf, to wait for
> > manual bind requests.
> 
> Please, let's make "manual bind" independent of modules.  In fact, it's less
> needed in case of modules, because you can control the order, in which they are
> loaded.

No, definitely not. If you have 10 times the same piece of hardware, it
has absolutely nothing to do with module load order, what modprobe will
do with the 10 instances without any control. It is already an issue
with storage controllers with thousends of disks connected.

> When manual bind is really needed is the case of the monolithic kernel.

I couldn't care less about monolithic kernels and controlling binding of
devices. These requirements have almost zero overlap. But sure, you can easily
make the module parameters working for that, with prepended driver names.

> Every driver has a name, so we should be able to refer to it before it's loaded.

To keep around a predefined list of possible future drivers loaded in the kernel?
I'm sure, we don't want that.

>  There should be a way to tell the kernel not to autobind e.g. orinoco_cs,
> whether it's a module or an in-kernel driver. 

But not that way. You want to compile that list into in the kernel? Or where
should your monolithic kernel get that list from?

> In the later case, we want some kind of kernel command line support.

Well, I don't think the former case should happen at all.

Thanks,
Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Dmitry Torokhov]

On Sunday 11 December 2005 01:43, Kay Sievers wrote:
> add "autobind" control to modules to specify device binding policy
> 
> This adds a sysfs control to every driver to control the automatic
> binding of drivers to devices. If set to "0", the driver will only
> bind devices if explicitely asked for, by using the "bind" file.
> 

Can we please change name to "bind_mode" so I can convert serio bus
to use driver core instead of implementing its own mechanism but won't
break few users who use it right now?

-- 
Dmitry


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Dominik Brodowski]

Hi,

On Sun, Dec 11, 2005 at 05:13:10PM +0100, Kay Sievers wrote:
> On Sun, Dec 11, 2005 at 10:48:56AM -0500, Pavel Roskin wrote:
> > Quoting Kay Sievers <kay.sievers@vrfy.org>:
> > 
> > > This quick hack works for me, but does it at the driver level, which is
> > > nicer to use than a global bus control.
> > >
> > > If the driver is already loaded, it can be controlled in sysfs or it can
> > > be passed to modprobe and the driver gets initialized with that setting.
> > > That way, modules/drivers can be set-up in modprobe.conf, to wait for
> > > manual bind requests.
> > 
> > Please, let's make "manual bind" independent of modules.  In fact, it's less
> > needed in case of modules, because you can control the order, in which they are
> > loaded.
> 
> No, definitely not. If you have 10 times the same piece of hardware, it
> has absolutely nothing to do with module load order, what modprobe will
> do with the 10 instances without any control. It is already an issue
> with storage controllers with thousends of disks connected.
> 
> > When manual bind is really needed is the case of the monolithic kernel.
> 
> I couldn't care less about monolithic kernels and controlling binding of
> devices. These requirements have almost zero overlap. But sure, you can easily
> make the module parameters working for that, with prepended driver names.
> 
> > Every driver has a name, so we should be able to refer to it before it's loaded.
> 
> To keep around a predefined list of possible future drivers loaded in the kernel?
> I'm sure, we don't want that.
> 
> >  There should be a way to tell the kernel not to autobind e.g. orinoco_cs,
> > whether it's a module or an in-kernel driver. 
> 
> But not that way. You want to compile that list into in the kernel? Or where
> should your monolithic kernel get that list from?
> 
> > In the later case, we want some kind of kernel command line support.
> 
> Well, I don't think the former case should happen at all.

Kay, I really like your patch and the approach it uses! Many thanks for
that!

Now, concerning the issue Pavel notices: would it be acceptable if drivers
can add a definition for a module parameter using e.g.

MODULE_PARAM_AUTOLOAD(orinoco_cs_driver.driver);

which then expands to a "normal" module parameter, being available _both_ on
module probing and on a monolithic kernel? If so, I'll write a patch which
does so.

Thanks,
	Dominik




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Dominik Brodowski]

Hi,

On Sun, Dec 11, 2005 at 12:20:04PM -0500, Dmitry Torokhov wrote:
> On Sunday 11 December 2005 01:43, Kay Sievers wrote:
> > add "autobind" control to modules to specify device binding policy
> > 
> > This adds a sysfs control to every driver to control the automatic
> > binding of drivers to devices. If set to "0", the driver will only
> > bind devices if explicitely asked for, by using the "bind" file.
> > 
> 
> Can we please change name to "bind_mode" so I can convert serio bus
> to use driver core instead of implementing its own mechanism but won't
> break few users who use it right now?

Well, we'd need to decide on the semantics then -- Kay has "0" and "1", you
have "manual" and "auto"... I have a slight preference for the verbose names,
for this would make the patch I suggest (see other mail) a bit easier to
write :-)

Thanks,
	Dominik


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Kay Sievers]

On Sun, Dec 11, 2005 at 08:59:20PM +0100, Dominik Brodowski wrote:
> On Sun, Dec 11, 2005 at 05:13:10PM +0100, Kay Sievers wrote:
> > On Sun, Dec 11, 2005 at 10:48:56AM -0500, Pavel Roskin wrote:
> > > Quoting Kay Sievers <kay.sievers@vrfy.org>:
> > > 
> > > > This quick hack works for me, but does it at the driver level, which is
> > > > nicer to use than a global bus control.
> > > >
> > > > If the driver is already loaded, it can be controlled in sysfs or it can
> > > > be passed to modprobe and the driver gets initialized with that setting.
> > > > That way, modules/drivers can be set-up in modprobe.conf, to wait for
> > > > manual bind requests.
> > > 
> > > Please, let's make "manual bind" independent of modules.  In fact, it's less
> > > needed in case of modules, because you can control the order, in which they are
> > > loaded.
> > 
> > No, definitely not. If you have 10 times the same piece of hardware, it
> > has absolutely nothing to do with module load order, what modprobe will
> > do with the 10 instances without any control. It is already an issue
> > with storage controllers with thousends of disks connected.
> > 
> > > When manual bind is really needed is the case of the monolithic kernel.
> > 
> > I couldn't care less about monolithic kernels and controlling binding of
> > devices. These requirements have almost zero overlap. But sure, you can easily
> > make the module parameters working for that, with prepended driver names.
> > 
> > > Every driver has a name, so we should be able to refer to it before it's loaded.
> > 
> > To keep around a predefined list of possible future drivers loaded in the kernel?
> > I'm sure, we don't want that.
> > 
> > >  There should be a way to tell the kernel not to autobind e.g. orinoco_cs,
> > > whether it's a module or an in-kernel driver. 
> > 
> > But not that way. You want to compile that list into in the kernel? Or where
> > should your monolithic kernel get that list from?
> > 
> > > In the later case, we want some kind of kernel command line support.
> > 
> > Well, I don't think the former case should happen at all.
> 
> Kay, I really like your patch and the approach it uses! Many thanks for
> that!
> 
> Now, concerning the issue Pavel notices: would it be acceptable if drivers
> can add a definition for a module parameter using e.g.
> 
> MODULE_PARAM_AUTOLOAD(orinoco_cs_driver.driver);
> 
> which then expands to a "normal" module parameter, being available _both_ on
> module probing and on a monolithic kernel? If so, I'll write a patch which
> does so.

If we go that road, we may not want to do the "default modrobe parameter"
handling hack at all and just add a "bind_mode" parameter to every module
which wants to support boot prompt or modprobe parameters. All I care, is
not to have a magic policy list for possibly loaded drivers in the kernel.

It may be a bit cleaner with the normal kernel parameter too and should work
the same way with modular and compiled-in drivers. "bind_mode" setting
init support would not be available then without adding the parameter to
every module which needs it, but that's acceptable I think.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Kay Sievers]

On Sun, Dec 11, 2005 at 09:00:31PM +0100, Dominik Brodowski wrote:
> Hi,
> 
> On Sun, Dec 11, 2005 at 12:20:04PM -0500, Dmitry Torokhov wrote:
> > On Sunday 11 December 2005 01:43, Kay Sievers wrote:
> > > add "autobind" control to modules to specify device binding policy
> > > 
> > > This adds a sysfs control to every driver to control the automatic
> > > binding of drivers to devices. If set to "0", the driver will only
> > > bind devices if explicitely asked for, by using the "bind" file.
> > > 
> > 
> > Can we please change name to "bind_mode" so I can convert serio bus
> > to use driver core instead of implementing its own mechanism but won't
> > break few users who use it right now?
> 
> Well, we'd need to decide on the semantics then -- Kay has "0" and "1", you
> have "manual" and "auto"... I have a slight preference for the verbose names,
> for this would make the patch I suggest (see other mail) a bit easier to
> write :-)

Sure, that's fine, if there is the possibility of the binding behavior
to ever become more than a boolean.

Thanks,
Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Kay Sievers]

On Sun, Dec 11, 2005 at 07:43:48AM +0100, Kay Sievers wrote:
> On Fri, Dec 09, 2005 at 08:20:41PM -0800, Greg KH wrote:
> > On Thu, Dec 08, 2005 at 04:31:45PM +0100, Kay Sievers wrote:
> > > Wouldn't it make the most sense to have a generic flag to pass to _any_
> > > driver to skip the bus probing and wait for a manual bind? This would be
> > > useful for the storage controllers too, that have 1000's of disks connected,
> > > cause you don't really want to trigger all that buses at once with
> > > a modprobe.
> > 
> > Yes, that would be nice to have.
> > 
> > > That way, you would just need to disable all autobinding with the module
> > > configuration and depend on the bus device events to match a given
> > > configuration to "manually" enable every device with the udev event.
> > 
> > Crazy distro installer authors have suggested that we have a way to
> > disable all autobinding for a bus somehow, so they can do the binding
> > themselves.  They might not be so crazy after all :)
> > 
> > But as the codepaths for the "autobind" and the "manual bind" are almost
> > identical, it might be tough to disable the automatic stuff...
> 
> This quick hack works for me, but does it at the driver level, which is
> nicer to use than a global bus control.

New version, which does not do the dirty "default parameters" trick. It
depends on a regular module parameter, if "bind_mode" control at module
load or boot prompt is needed. It uses "auto" and "manual" as the values
and the sysfs file in the driver directory is called "bind_mode".

Thanks,
Kay

---
add "bind_mode" control to drivers, to specify device binding policy

This adds a sysfs control to every driver to control the automatic
binding of drivers to devices. If set to "manual", the driver will
only bind devices if explicitely asked for, by using the "bind" file.

  $ tree /sys/bus/usb/drivers/ov511/
  /sys/bus/usb/drivers/ov511/
  |-- 3-1:1.0 -> ../../../../devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0
  |-- bind
  |-- bind_mode
  |-- module -> ../../../../module/ov511
  `-- unbind

"autobind=manual" disables the automatic device binding:
  $ modprobe ov511
  $ cat /sys/bus/usb/drivers/ov511/bind_mode
  auto

  $ rmmod ov511
  $ modprobe ov511 bind_mode=manual
  $ cat /sys/bus/usb/drivers/ov511/bind_mode
  manual

Drivers need to implement a module parameter to initialize bind_mode, if
they want to offer control over bind_mode at module load or boot prompt.
---

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index fa601b0..4feeb78 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -143,6 +143,19 @@ static int driver_helper(struct device *
 	return 0;
 }
 
+static ssize_t show_bind_mode(struct device_driver *drv, char *buf)
+{
+	return sprintf(buf, "%s\n", drv->bind_mode ? "manual" : "auto");
+}
+static ssize_t store_bind_mode(struct device_driver *drv,
+			      const char *buf, size_t count)
+{
+	if (driver_set_bind_mode(drv, buf))
+		return -EINVAL;
+	return count;
+}
+static DRIVER_ATTR(bind_mode, S_IRUSR | S_IWUSR, show_bind_mode, store_bind_mode);
+
 static ssize_t driver_unbind(struct device_driver *drv,
 			     const char *buf, size_t count)
 {
@@ -444,13 +457,15 @@ int bus_add_driver(struct device_driver 
 			return error;
 		}
 
-		driver_attach(drv);
+		if (drv->bind_mode = 0)
+			driver_attach(drv);
 		klist_add_tail(&drv->knode_bus, &bus->klist_drivers);
 		module_add_driver(drv->owner, drv);
 
 		driver_add_attrs(bus, drv);
 		driver_create_file(drv, &driver_attr_unbind);
 		driver_create_file(drv, &driver_attr_bind);
+		driver_create_file(drv, &driver_attr_bind_mode);
 	}
 	return error;
 }
@@ -468,6 +483,7 @@ int bus_add_driver(struct device_driver 
 void bus_remove_driver(struct device_driver * drv)
 {
 	if (drv->bus) {
+		driver_remove_file(drv, &driver_attr_bind_mode);
 		driver_remove_file(drv, &driver_attr_bind);
 		driver_remove_file(drv, &driver_attr_unbind);
 		driver_remove_attrs(drv->bus, drv);
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 3b419c9..048db68 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -110,6 +110,8 @@ int driver_probe_device(struct device_dr
 static int __device_attach(struct device_driver * drv, void * data)
 {
 	struct device * dev = data;
+	if (drv->bind_mode = 1)
+		return 0;
 	return driver_probe_device(drv, dev);
 }
 
diff --git a/drivers/base/driver.c b/drivers/base/driver.c
index 161f3a3..c6e2fc4 100644
--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@ -214,11 +214,23 @@ struct device_driver *driver_find(const 
 	return NULL;
 }
 
+int driver_set_bind_mode(struct device_driver * drv, const char *mode)
+{
+	if (!strcmp(mode, "manual"))
+		drv->bind_mode = 1;
+	else if (!strcmp(mode, "auto"))
+		drv->bind_mode = 0;
+	else
+		return -ENOENT;
+	return 0;
+}
+
 EXPORT_SYMBOL_GPL(driver_register);
 EXPORT_SYMBOL_GPL(driver_unregister);
 EXPORT_SYMBOL_GPL(get_driver);
 EXPORT_SYMBOL_GPL(put_driver);
 EXPORT_SYMBOL_GPL(driver_find);
+EXPORT_SYMBOL_GPL(driver_set_bind_mode);
 
 EXPORT_SYMBOL_GPL(driver_create_file);
 EXPORT_SYMBOL_GPL(driver_remove_file);
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 1b4adb1..eb03974 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -168,7 +168,9 @@ int usb_register(struct usb_driver *new_
 	new_driver->driver.probe = usb_probe_interface;
 	new_driver->driver.remove = usb_unbind_interface;
 	new_driver->driver.owner = new_driver->owner;
-
+	if (new_driver->bind_mode)
+		driver_set_bind_mode(&new_driver->driver,
+				     new_driver->bind_mode);
 	usb_lock_all_devices();
 	retval = driver_register(&new_driver->driver);
 	usb_unlock_all_devices();
diff --git a/drivers/usb/media/ov511.c b/drivers/usb/media/ov511.c
index 036c485..3f31c2a 100644
--- a/drivers/usb/media/ov511.c
+++ b/drivers/usb/media/ov511.c
@@ -84,6 +84,10 @@
  * (See ov511.txt for detailed descriptions of these)
  **********************************************************************/
 
+static char bind_mode[8];
+module_param_string(bind_mode, bind_mode, sizeof(bind_mode), 0);
+MODULE_PARM_DESC(bind_mode, "Driver core auto/manual device binding");
+
 /* These variables (and all static globals) default to zero */
 static int autobright		= 1;
 static int autogain		= 1;
@@ -6012,7 +6016,8 @@ static struct usb_driver ov511_driver = 
 	.name =		"ov511",
 	.id_table =	device_table,
 	.probe =	ov51x_probe,
-	.disconnect =	ov51x_disconnect
+	.disconnect =	ov51x_disconnect,
+	.bind_mode =	bind_mode,
 };
 
 /****************************************************************************
diff --git a/include/linux/device.h b/include/linux/device.h
index 0cdee78..9ac1b1a 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -98,6 +98,7 @@ struct device_driver {
 	struct klist_node	knode_bus;
 
 	struct module		* owner;
+	int			bind_mode;
 
 	int	(*probe)	(struct device * dev);
 	int	(*remove)	(struct device * dev);
@@ -128,6 +129,7 @@ struct driver_attribute driver_attr_##_n
 
 extern int driver_create_file(struct device_driver *, struct driver_attribute *);
 extern void driver_remove_file(struct device_driver *, struct driver_attribute *);
+extern int driver_set_bind_mode(struct device_driver * drv, const char *mode);
 
 extern int driver_for_each_device(struct device_driver * drv, struct device * start,
 				  void * data, int (*fn)(struct device *, void *));
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 7a20997..61a9210 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -589,6 +589,7 @@ struct usb_driver {
 	const struct usb_device_id *id_table;
 
 	struct device_driver driver;
+	char *bind_mode;
 };
 #define	to_usb_driver(d) container_of(d, struct usb_driver, driver)
 



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Dominik Brodowski]

Hi,

On Tue, Dec 13, 2005 at 05:55:04AM +0100, Kay Sievers wrote:
> New version, which does not do the dirty "default parameters" trick. It
> depends on a regular module parameter, if "bind_mode" control at module
> load or boot prompt is needed. It uses "auto" and "manual" as the values
> and the sysfs file in the driver directory is called "bind_mode".

Great, many thanks!

> index 036c485..3f31c2a 100644
> --- a/drivers/usb/media/ov511.c
> +++ b/drivers/usb/media/ov511.c
> @@ -84,6 +84,10 @@
>   * (See ov511.txt for detailed descriptions of these)
>   **********************************************************************/
>  
> +static char bind_mode[8];
> +module_param_string(bind_mode, bind_mode, sizeof(bind_mode), 0);
> +

The only thing which worries me is that we add quite some bytes to the
kernel here... What do you think about this?

#define module_param_bind_mode(driver)					\
	module_param_named(dont_bind, &driver->bind_mode, uint, 0);	\
	MODULE_PARM_DESC(bind_mode, "Do not bind this driver to "	\
				"devices automatically.");

Then we'd need to add

module_param_named(&ov511_driver.driver);

to ov511.c and get the same functionality.


Thanks,
	Dominik


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Kay Sievers]

On Tue, Dec 13, 2005 at 08:39:57PM +0100, Dominik Brodowski wrote:
> Hi,
> 
> On Tue, Dec 13, 2005 at 05:55:04AM +0100, Kay Sievers wrote:
> > New version, which does not do the dirty "default parameters" trick. It
> > depends on a regular module parameter, if "bind_mode" control at module
> > load or boot prompt is needed. It uses "auto" and "manual" as the values
> > and the sysfs file in the driver directory is called "bind_mode".
> 
> 
> The only thing which worries me is that we add quite some bytes to the
> kernel here... What do you think about this?
> 
> #define module_param_bind_mode(driver)					\
> 	module_param_named(dont_bind, &driver->bind_mode, uint, 0);	\
> 	MODULE_PARM_DESC(bind_mode, "Do not bind this driver to "	\
> 				"devices automatically.");
> 
> Then we'd need to add
> 
> module_param_named(&ov511_driver.driver);
> 
> to ov511.c and get the same functionality.

Yes, that we need to decide. I just wanted to see the alternative approach
and posted it. We need to find out if we want:
  "default module parameters"
    - which would work for all modules, without changes
    - like the first patch, but in a more generic way that
      also implements built-in early parameter parsing
or:
    "only modular drivers init support by default"
    - will work fine with the current infrastructure, but modules
      need to have the parameter added if they want boot parameter
      support

If "default module parameters" are something that is considered useful
for other possible use cases too, we may just go for it.

And another thing is the prameters textual value like "auto" and
"manual". If we never add a third option to it, we may stick with the sysfs
boolean, which is smaller and simpler to implement. Not sure what's the
best here.

Thanks,
Kay



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Dmitry Torokhov]

On 12/13/05, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
> And another thing is the prameters textual value like "auto" and
> "manual". If we never add a third option to it, we may stick with the sysfs
> boolean, which is smaller and simpler to implement. Not sure what's the
> best here.

I prefer textual values because:

1. They self-descriptive
2. They already used in kernel, so if you switch to numeric you'll
break userrspace
3. Implementation difference is insignificant.

--
Dmitry


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&opÌk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Kay Sievers]

On Tue, Dec 13, 2005 at 03:56:49PM -0500, Dmitry Torokhov wrote:
> On 12/13/05, Kay Sievers <kay.sievers@vrfy.org> wrote:
> >
> > And another thing is the prameters textual value like "auto" and
> > "manual". If we never add a third option to it, we may stick with the sysfs
> > boolean, which is smaller and simpler to implement. Not sure what's the
> > best here.
> 
> I prefer textual values because:

> 1. They self-descriptive

The same is true for sysfs booleans. No need to "describe" "autobind" on
and off, right?)

> 2. They already used in kernel, so if you switch to numeric you'll
> break userrspace

Ther are currently no such attributes at the driver level, right? So
this does not apply at all.

> 3. Implementation difference is insignificant.

Well, if a boolean is enough, I disagree. But I'm not sure if someone
will want to specify a third operation mode. Than the textual values
are a big advantage, sure.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Dmitry Torokhov]

On 12/13/05, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Tue, Dec 13, 2005 at 03:56:49PM -0500, Dmitry Torokhov wrote:
> > On 12/13/05, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > >
> > > And another thing is the prameters textual value like "auto" and
> > > "manual". If we never add a third option to it, we may stick with the sysfs
> > > boolean, which is smaller and simpler to implement. Not sure what's the
> > > best here.
> >
> > I prefer textual values because:
>
> > 1. They self-descriptive
>
> The same is true for sysfs booleans. No need to "describe" "autobind" on
> and off, right?)
>

If it is called autobindm but I am lobbying for "bind_mode". See serio
bus below.

> > 2. They already used in kernel, so if you switch to numeric you'll
> > break userrspace
>
> Ther are currently no such attributes at the driver level, right? So
> this does not apply at all.
>

serio bus has 'bind_mode" device and driver attributes. If we add them
to the driver core I would like them to be compatible so I could drop
them from serio bus itself.

> > 3. Implementation difference is insignificant.
>
> Well, if a boolean is enough, I disagree. But I'm not sure if someone
> will want to specify a third operation mode. Than the textual values
> are a big advantage, sure.
>

Hmm, I wonder what that mode will be.. "random"? ;)

--
Dmitry


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&opÌk
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Dominik Brodowski]

Hi,

On Tue, Dec 13, 2005 at 05:00:51PM -0500, Dmitry Torokhov wrote:
> > The same is true for sysfs booleans. No need to "describe" "autobind" on
> > and off, right?)
> >
> 
> If it is called autobindm but I am lobbying for "bind_mode". See serio
> bus below.

bind_mode is not self-explanatory. And the textual interface takes up more
space, and as we want to propagate this interface to as many drivers as
possible (I imagine), the cleaner and leaner the interface, the better :-)

> > > 2. They already used in kernel, so if you switch to numeric you'll
> > > break userrspace
> >
> > Ther are currently no such attributes at the driver level, right? So
> > this does not apply at all.
> >
> 
> serio bus has 'bind_mode" device and driver attributes. If we add them
> to the driver core I would like them to be compatible so I could drop
> them from serio bus itself.

Well, you can have both :-) -- and then, after a conversion period, drop one
or the other.

> > > 3. Implementation difference is insignificant.
> >
> > Well, if a boolean is enough, I disagree. But I'm not sure if someone
> > will want to specify a third operation mode. Than the textual values
> > are a big advantage, sure.
> >
> 
> Hmm, I wonder what that mode will be.. "random"? ;)

Yes, I cannot think of a third mode either... and 0 and 1 (which we can
"suggest" to users of the interface) are extendable to 2, if we ever need a
random or other mode...

	Dominik


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Dominik Brodowski]

Hi,

On Tue, Dec 13, 2005 at 11:54:42PM +0100, Dominik Brodowski wrote:
> Hi,
> 
> On Tue, Dec 13, 2005 at 05:00:51PM -0500, Dmitry Torokhov wrote:
> > > The same is true for sysfs booleans. No need to "describe" "autobind" on
> > > and off, right?)

Any progress in this regard? It seems to me that the solving of the few
outstanding issues has dropped off some in the pre-holiday season ... now in
the New Year, shall we try to solve them and get this feature into a
mergeable state? Or have I missed something and is it already on its way
into 2.6.16?

Thanks,
	Dominik


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Kay Sievers]

On Sun, Jan 08, 2006 at 10:36:30PM +0100, Dominik Brodowski wrote:
...
> > > > The same is true for sysfs booleans. No need to "describe" "autobind" on
> > > > and off, right?)
> 
> Any progress in this regard? It seems to me that the solving of the few
> outstanding issues has dropped off some in the pre-holiday season ... now in
> the New Year, shall we try to solve them and get this feature into a
> mergeable state? Or have I missed something and is it already on its way
> into 2.6.16?

No, nothing happened after the two alternative patches posted to the
list. We still need to decide on the syfs interface (bool vs. text) and
the "simple patch to the individual drivers" or go for the "default module
parameter".

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Christian Zoz]

On Mon, Jan 09, Kay Sievers wrote:
> On Sun, Jan 08, 2006 at 10:36:30PM +0100, Dominik Brodowski wrote:
> ...
> > > > > The same is true for sysfs booleans. No need to "describe" "autobind" on
> > > > > and off, right?)
> > 
> > Any progress in this regard? It seems to me that the solving of the few
> > outstanding issues has dropped off some in the pre-holiday season ... now in
> > the New Year, shall we try to solve them and get this feature into a
> > mergeable state? Or have I missed something and is it already on its way
> > into 2.6.16?
> 
> No, nothing happened after the two alternative patches posted to the
> list. We still need to decide on the syfs interface (bool vs. text) and
> the "simple patch to the individual drivers" or go for the "default module
> parameter".

I vote for an boolean interface (autobind) and the "default module
parameter". Boolean because autobind is self-explanatory and
light-weight. And default module parameter bebause i hate fiddling
with different driver behavior.

-- 

ciao, christian

睡眠不足はいい仕事の敵だ。


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Dominik Brodowski]

Hi,

For various reasons, it might be necessary to switch to a better driver for
a device -- Jean can tell of many examples, if needed. Currently, that's
possible using modprobe's blacklisting capability (in
module-init-tools-3.2.1, at least) -- but that's for monolithic kernels
only. While a blacklisting feature might also come useful in the kernel 
driver core level, udev may offer the chance to fix some broken "bindings"
if there's need to. We'd need a simple shell script like

#/bin/bash
#
# needs 4 arguments: devpath bus wrong_driver right_driver
#
$drivername = basename $(readlink /sys/$1/driver)
$device = basename $1
$bus = $2
$wrong_driver = $3
$right_driver = $4

if [ $drivername = $wrong_driver ]; then
	echo -n "$device" > /sys/$devpath/driver/unbind
	echo -n "$device" > /sys/bus/$2/$right_driver/driver/bind
fi;


Then adding udev rules like

ACTION="add", BUS="pci", RUN+="/bin/sh -c /sbin/check_blacklist $devpath $bus hostap_pci orinoco_pci'"

is very easy, and such rules could even be generated by yet another tool
which then echos into all relevant "uevent" files to run this script..


Or is all this already implemented? But differently? Should it be done at
the kernel driver core level?

Thanks,
	Dominik


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Bill Nottingham]

Dominik Brodowski (linux@dominikbrodowski.net) said: 
> Hi,
> 
> For various reasons, it might be necessary to switch to a better driver for
> a device -- Jean can tell of many examples, if needed. Currently, that's
> possible using modprobe's blacklisting capability (in
> module-init-tools-3.2.1, at least) -- but that's for monolithic kernels
> only.

Why is the blacklisting for monolithic kernels only?

Bill


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Jean Tourrilhes]

On Wed, Dec 07, 2005 at 05:52:11PM -0500, Bill Nottingham wrote:
> Dominik Brodowski (linux@dominikbrodowski.net) said: 
> > Hi,
> > 
> > For various reasons, it might be necessary to switch to a better driver for
> > a device -- Jean can tell of many examples, if needed. Currently, that's
> > possible using modprobe's blacklisting capability (in
> > module-init-tools-3.2.1, at least) -- but that's for monolithic kernels
> > only.
> 
> Why is the blacklisting for monolithic kernels only?
> 
> Bill

	Actually, I think Dominik inverted the two and that
blacklisting apply only to modular kernel and would fail with
monolithic kernel (because the drivers are already pre-loaded).
	Anyway, that's not the point, and it does not really
matter. The point is that blacklisting is clearly not able to deal
with the reality and complexity of Pcmcia drivers (even for fully
modular kernels). If you want more details, feel free to check the
archive of the Pcmcia mailing list.
	Therefore, Dominik is proposing a per card overide using the
unbind/bind feature.

	Have fun...

	Jean


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Greg KH]

On Wed, Dec 07, 2005 at 10:37:21PM +0100, Dominik Brodowski wrote:
> Hi,
> 
> For various reasons, it might be necessary to switch to a better driver for
> a device -- Jean can tell of many examples, if needed. Currently, that's
> possible using modprobe's blacklisting capability (in
> module-init-tools-3.2.1, at least) -- but that's for monolithic kernels
> only. While a blacklisting feature might also come useful in the kernel 
> driver core level, udev may offer the chance to fix some broken "bindings"
> if there's need to. We'd need a simple shell script like
> 
> #/bin/bash
> #
> # needs 4 arguments: devpath bus wrong_driver right_driver
> #
> $drivername = basename $(readlink /sys/$1/driver)
> $device = basename $1
> $bus = $2
> $wrong_driver = $3
> $right_driver = $4
> 
> if [ $drivername = $wrong_driver ]; then
> 	echo -n "$device" > /sys/$devpath/driver/unbind
> 	echo -n "$device" > /sys/bus/$2/$right_driver/driver/bind
> fi;
> 
> 
> Then adding udev rules like
> 
> ACTION="add", BUS="pci", RUN+="/bin/sh -c /sbin/check_blacklist $devpath $bus hostap_pci orinoco_pci'"
> 
> is very easy, and such rules could even be generated by yet another tool
> which then echos into all relevant "uevent" files to run this script..
> 
> 
> Or is all this already implemented? But differently? Should it be done at
> the kernel driver core level?

So what is the main problem you are trying to fix here?  Drivers binding
to devices that they should not bind to?  Why are they binding to these
devices in the first place?  Would something like the libusual code in
-mm work better for this instead?

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: grey- and blacklisting drivers [Was: Re: Using the "best available" driver]

[Jean Tourrilhes]

On Wed, Dec 07, 2005 at 05:23:32PM -0800, Greg KH wrote:
> 
	Hi Greg,

	Welcome on board.

> So what is the main problem you are trying to fix here?

	To get you up to speed, you may want to read these :
http://lists.infradead.org/pipermail/linux-pcmcia/2005-December/002957.html
http://lists.infradead.org/pipermail/linux-pcmcia/2005-December/002997.html

	The problem to resolve : two Pcmcia drivers with partial
hardware overlap. This happen quite often in the Pcmcia/Wireless
world.
	Basically, we want to offer fine grained control over driver
binding in a user friendly way and push that in distros. The basic
infrastructure is there (sysfs bind/unbind), what's missing is the
user friendly wrapping around (automatic on hotplug event, nice config
file, ...).

> Drivers binding to devices that they should not bind to?

	No, that's not what we are trying to solve.

>  Why are they binding to these devices in the first place?

	Because those drivers do support the device.

>  Would something like the libusual code in -mm work better for this instead?

	I personally don't know what it does.

> thanks,
> 
> greg k-h

	Have fun...

	Jean


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel