Re: Two module-init-

Re: Two module-init-

[Rusty Russell]

On Wed, 2005-11-30 at 14:09 +0000, Scott James Remnant wrote:
> Hi Rusty,
> 
> Attached are two patches to module-init-tools from Ubuntu.
> 
> The first (input_table_size) is a catch-up with 2.6.15, it's adding an
> extra field to the input_device_id struct; m-u-t needs updating to be
> able to read the modules correctly.

Hi Scott,

	Unfortunately, it's not that simple.  Your patch will break previous
kernels, which have a smaller structure.  I've had the discussion years
ago with the input people on using module aliases, and it's not entirely
trivial.  I will prepare another patch, however.

Meanwhile, as noone seems to use swbit in struct input_device_id,
perhaps we can remove it for 2.6.15?

> The second (use_blacklist) adds a "-b" flag to modprobe that performs
> blacklist checking on those modules listed on the command line, it's
> handy for use when calling modprobe from udev for those subsystems
> without MODALIAS yet (input, ccw, etc.)

Hmm, well, the answer to that is the same as above.  ccw should have
support now, so it's just input we're missing I think.

Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

Re: Two module-init-

[Scott James Remnant]

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

On Fri, 2005-12-02 at 11:12 +1100, Rusty Russell wrote:

> On Wed, 2005-11-30 at 14:09 +0000, Scott James Remnant wrote:
> > Hi Rusty,
> > 
> > Attached are two patches to module-init-tools from Ubuntu.
> > 
> > The first (input_table_size) is a catch-up with 2.6.15, it's adding an
> > extra field to the input_device_id struct; m-u-t needs updating to be
> > able to read the modules correctly.
> 
> Unfortunately, it's not that simple.  Your patch will break previous
> kernels, which have a smaller structure.  I've had the discussion years
> ago with the input people on using module aliases, and it's not entirely
> trivial.  I will prepare another patch, however.
> 
Are the modules.*map files intended to be deprecated entirely in favour
of aliases?  The problem this patch fixed was that the parser couldn't
read the tables, so produced invalid output for the modules (ie. an
empty modules.inputmap).

Scott
-- 
Scott James Remnant
scott@ubuntu.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Two module-init-

[Rusty Russell]

On Fri, 2005-12-02 at 09:01 +0000, Scott James Remnant wrote:
> On Fri, 2005-12-02 at 11:12 +1100, Rusty Russell wrote:
> 
> > On Wed, 2005-11-30 at 14:09 +0000, Scott James Remnant wrote:
> > > Hi Rusty,
> > > 
> > > Attached are two patches to module-init-tools from Ubuntu.
> > > 
> > > The first (input_table_size) is a catch-up with 2.6.15, it's adding an
> > > extra field to the input_device_id struct; m-u-t needs updating to be
> > > able to read the modules correctly.
> > 
> > Unfortunately, it's not that simple.  Your patch will break previous
> > kernels, which have a smaller structure.  I've had the discussion years
> > ago with the input people on using module aliases, and it's not entirely
> > trivial.  I will prepare another patch, however.
> > 
> Are the modules.*map files intended to be deprecated entirely in favour
> of aliases?  The problem this patch fixed was that the parser couldn't
> read the tables, so produced invalid output for the modules (ie. an
> empty modules.inputmap).

Yes, but now it will produce a bad modules.inputmap for previous
kernels.

Here's the patch for modalias support for input classes.  It uses
comma-separated numbers, and doesn't describe all the potential keys (no
module currently cares, and that would make the strings huge).  The
changes to input.h are to move the definitions needed by file2alias
outside __KERNEL__.  I chose not to move those definitions to
mod_devicetable.h, because there are so many that it might break compile
of something else in the kernel.

The rest is fairly straightforward.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (authored)
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.6.15-rc4/drivers/input/input.c working-2.6.15-rc4-input-modalias/drivers/input/input.c
--- linux-2.6.15-rc4/drivers/input/input.c	2005-12-02 11:00:18.000000000 +1100
+++ working-2.6.15-rc4-input-modalias/drivers/input/input.c	2005-12-02 17:25:03.000000000 +1100
@@ -529,10 +529,49 @@ INPUT_DEV_STRING_ATTR_SHOW(name);
 INPUT_DEV_STRING_ATTR_SHOW(phys);
 INPUT_DEV_STRING_ATTR_SHOW(uniq);
 
+static int print_modalias_bits(char *buf, char prefix, unsigned long *arr,
+			       unsigned int min, unsigned int max)
+{
+	int len, i;
+
+	len = sprintf(buf, "%c", prefix);
+	for (i = min; i < max; i++)
+		if (arr[LONG(i)] & BIT(i))
+			len += sprintf(buf+len, "%X,", i);
+	return len;
+}
+	
+static ssize_t input_dev_show_modalias(struct class_device *dev, char *buf)
+{
+	struct input_dev *id = to_input_dev(dev);
+	ssize_t len = 0;
+
+	len += sprintf(buf+len, "input:b%04Xv%04Xp%04Xe%04X-",
+		       id->id.bustype,
+		       id->id.vendor,
+		       id->id.product,
+		       id->id.version);
+
+	len += print_modalias_bits(buf+len, 'e', id->evbit, 0, EV_MAX);
+	len += print_modalias_bits(buf+len, 'k', id->keybit,
+				   KEY_MIN_INTERESTING, KEY_MAX);
+	len += print_modalias_bits(buf+len, 'r', id->relbit, 0, REL_MAX);
+	len += print_modalias_bits(buf+len, 'a', id->absbit, 0, ABS_MAX);
+	len += print_modalias_bits(buf+len, 'm', id->mscbit, 0, MSC_MAX);
+	len += print_modalias_bits(buf+len, 'l', id->ledbit, 0, LED_MAX);
+	len += print_modalias_bits(buf+len, 's', id->sndbit, 0, SND_MAX);
+	len += print_modalias_bits(buf+len, 'f', id->ffbit, 0, FF_MAX);
+	len += print_modalias_bits(buf+len, 'w', id->swbit, 0, SW_MAX);
+	len += sprintf(buf+len, "\n");
+	return len;
+}
+static CLASS_DEVICE_ATTR(modalias, S_IRUGO, input_dev_show_modalias, NULL);
+
 static struct attribute *input_dev_attrs[] = {
 	&class_device_attr_name.attr,
 	&class_device_attr_phys.attr,
 	&class_device_attr_uniq.attr,
+	&class_device_attr_modalias.attr,
 	NULL
 };
 
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.6.15-rc4/include/linux/input.h working-2.6.15-rc4-input-modalias/include/linux/input.h
--- linux-2.6.15-rc4/include/linux/input.h	2005-12-02 11:01:11.000000000 +1100
+++ working-2.6.15-rc4-input-modalias/include/linux/input.h	2005-12-02 15:51:15.000000000 +1100
@@ -18,6 +18,7 @@
 #include <sys/ioctl.h>
 #include <asm/types.h>
 #endif
+#include <linux/mod_devicetable.h>
 
 /*
  * The event structure itself
@@ -511,6 +512,8 @@ struct input_absinfo {
 #define KEY_FN_S		0x1e3
 #define KEY_FN_B		0x1e4
 
+/* We avoid low common keys in module aliases so they don't get huge. */
+#define KEY_MIN_INTERESTING	KEY_MUTE
 #define KEY_MAX			0x1ff
 
 /*
@@ -793,6 +796,44 @@ struct ff_effect {
 
 #define FF_MAX		0x7f
 
+struct input_device_id {
+
+	kernel_ulong_t flags;
+
+	struct input_id id;
+
+	kernel_ulong_t evbit[EV_MAX/BITS_PER_LONG+1];
+	kernel_ulong_t keybit[KEY_MAX/BITS_PER_LONG+1];
+	kernel_ulong_t relbit[REL_MAX/BITS_PER_LONG+1];
+	kernel_ulong_t absbit[ABS_MAX/BITS_PER_LONG+1];
+	kernel_ulong_t mscbit[MSC_MAX/BITS_PER_LONG+1];
+	kernel_ulong_t ledbit[LED_MAX/BITS_PER_LONG+1];
+	kernel_ulong_t sndbit[SND_MAX/BITS_PER_LONG+1];
+	kernel_ulong_t ffbit[FF_MAX/BITS_PER_LONG+1];
+	kernel_ulong_t swbit[SW_MAX/BITS_PER_LONG+1];
+
+	kernel_ulong_t driver_info;
+};
+
+/*
+ * Structure for hotplug & device<->driver matching.
+ */
+
+#define INPUT_DEVICE_ID_MATCH_BUS	1
+#define INPUT_DEVICE_ID_MATCH_VENDOR	2
+#define INPUT_DEVICE_ID_MATCH_PRODUCT	4
+#define INPUT_DEVICE_ID_MATCH_VERSION	8
+
+#define INPUT_DEVICE_ID_MATCH_EVBIT	0x010
+#define INPUT_DEVICE_ID_MATCH_KEYBIT	0x020
+#define INPUT_DEVICE_ID_MATCH_RELBIT	0x040
+#define INPUT_DEVICE_ID_MATCH_ABSBIT	0x080
+#define INPUT_DEVICE_ID_MATCH_MSCIT	0x100
+#define INPUT_DEVICE_ID_MATCH_LEDBIT	0x200
+#define INPUT_DEVICE_ID_MATCH_SNDBIT	0x400
+#define INPUT_DEVICE_ID_MATCH_FFBIT	0x800
+#define INPUT_DEVICE_ID_MATCH_SWBIT	0x1000
+
 #ifdef __KERNEL__
 
 /*
@@ -901,49 +942,11 @@ struct input_dev {
 };
 #define to_input_dev(d) container_of(d, struct input_dev, cdev)
 
-/*
- * Structure for hotplug & device<->driver matching.
- */
-
-#define INPUT_DEVICE_ID_MATCH_BUS	1
-#define INPUT_DEVICE_ID_MATCH_VENDOR	2
-#define INPUT_DEVICE_ID_MATCH_PRODUCT	4
-#define INPUT_DEVICE_ID_MATCH_VERSION	8
-
-#define INPUT_DEVICE_ID_MATCH_EVBIT	0x010
-#define INPUT_DEVICE_ID_MATCH_KEYBIT	0x020
-#define INPUT_DEVICE_ID_MATCH_RELBIT	0x040
-#define INPUT_DEVICE_ID_MATCH_ABSBIT	0x080
-#define INPUT_DEVICE_ID_MATCH_MSCIT	0x100
-#define INPUT_DEVICE_ID_MATCH_LEDBIT	0x200
-#define INPUT_DEVICE_ID_MATCH_SNDBIT	0x400
-#define INPUT_DEVICE_ID_MATCH_FFBIT	0x800
-#define INPUT_DEVICE_ID_MATCH_SWBIT	0x1000
-
 #define INPUT_DEVICE_ID_MATCH_DEVICE\
 	(INPUT_DEVICE_ID_MATCH_BUS | INPUT_DEVICE_ID_MATCH_VENDOR | INPUT_DEVICE_ID_MATCH_PRODUCT)
 #define INPUT_DEVICE_ID_MATCH_DEVICE_AND_VERSION\
 	(INPUT_DEVICE_ID_MATCH_DEVICE | INPUT_DEVICE_ID_MATCH_VERSION)
 
-struct input_device_id {
-
-	unsigned long flags;
-
-	struct input_id id;
-
-	unsigned long evbit[NBITS(EV_MAX)];
-	unsigned long keybit[NBITS(KEY_MAX)];
-	unsigned long relbit[NBITS(REL_MAX)];
-	unsigned long absbit[NBITS(ABS_MAX)];
-	unsigned long mscbit[NBITS(MSC_MAX)];
-	unsigned long ledbit[NBITS(LED_MAX)];
-	unsigned long sndbit[NBITS(SND_MAX)];
-	unsigned long ffbit[NBITS(FF_MAX)];
-	unsigned long swbit[NBITS(SW_MAX)];
-
-	unsigned long driver_info;
-};
-
 struct input_handle;
 
 struct input_handler {
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.6.15-rc4/scripts/mod/file2alias.c working-2.6.15-rc4-input-modalias/scripts/mod/file2alias.c
--- linux-2.6.15-rc4/scripts/mod/file2alias.c	2005-12-02 11:01:24.000000000 +1100
+++ working-2.6.15-rc4-input-modalias/scripts/mod/file2alias.c	2005-12-02 16:30:20.000000000 +1100
@@ -16,8 +16,10 @@
  * use either stdint.h or inttypes.h for the rest. */
 #if KERNEL_ELFCLASS == ELFCLASS32
 typedef Elf32_Addr	kernel_ulong_t;
+#define BITS_PER_LONG 32
 #else
 typedef Elf64_Addr	kernel_ulong_t;
+#define BITS_PER_LONG 64
 #endif
 #ifdef __sun__
 #include <inttypes.h>
@@ -35,6 +37,7 @@ typedef unsigned char	__u8;
  * even potentially has different endianness and word sizes, since 
  * we handle those differences explicitly below */
 #include "../../include/linux/mod_devicetable.h"
+#include "../../include/linux/input.h"
 
 #define ADD(str, sep, cond, field)                              \
 do {                                                            \
@@ -366,6 +369,61 @@ static int do_i2c_entry(const char *file
 	return 1;
 }
 
+#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+
+static void do_input(char *alias,
+		     kernel_ulong_t *arr, unsigned int min, unsigned int max)
+{
+	unsigned int i;
+	for (i = min; i < max; i++) {
+		if (arr[i/BITS_PER_LONG] & (1 << (i%BITS_PER_LONG)))
+			sprintf(alias+strlen(alias), "%X,*", i);
+	}
+}
+
+/* input:b0v0p0e0-eXkXrXaXmXlXsXfXwX where X is comma-separated %02X. */
+static int do_input_entry(const char *filename, struct input_device_id *id,
+			  char *alias)
+{
+	sprintf(alias, "input:");
+
+	ADD(alias, "b", id->flags&INPUT_DEVICE_ID_MATCH_BUS, id->id.bustype);
+	ADD(alias, "v", id->flags&INPUT_DEVICE_ID_MATCH_VENDOR, id->id.vendor);
+	ADD(alias, "p", id->flags&INPUT_DEVICE_ID_MATCH_PRODUCT,
+	    id->id.product);
+	ADD(alias, "e", id->flags&INPUT_DEVICE_ID_MATCH_VERSION,
+	    id->id.version);
+
+	sprintf(alias + strlen(alias), "-e*");
+	if (id->flags&INPUT_DEVICE_ID_MATCH_EVBIT)
+		do_input(alias, id->evbit, 0, EV_MAX);
+	sprintf(alias + strlen(alias), "k*");
+	if (id->flags&INPUT_DEVICE_ID_MATCH_KEYBIT)
+		do_input(alias, id->keybit, KEY_MIN_INTERESTING, KEY_MAX);
+	sprintf(alias + strlen(alias), "r*");
+	if (id->flags&INPUT_DEVICE_ID_MATCH_RELBIT)
+		do_input(alias, id->relbit, 0, REL_MAX);
+	sprintf(alias + strlen(alias), "a*");
+	if (id->flags&INPUT_DEVICE_ID_MATCH_ABSBIT)
+		do_input(alias, id->absbit, 0, ABS_MAX);
+	sprintf(alias + strlen(alias), "m*");
+	if (id->flags&INPUT_DEVICE_ID_MATCH_MSCIT)
+		do_input(alias, id->mscbit, 0, MSC_MAX);
+	sprintf(alias + strlen(alias), "l*");
+	if (id->flags&INPUT_DEVICE_ID_MATCH_LEDBIT)
+		do_input(alias, id->ledbit, 0, LED_MAX);
+	sprintf(alias + strlen(alias), "s*");
+	if (id->flags&INPUT_DEVICE_ID_MATCH_SNDBIT)
+		do_input(alias, id->sndbit, 0, SND_MAX);
+	sprintf(alias + strlen(alias), "f*");
+	if (id->flags&INPUT_DEVICE_ID_MATCH_FFBIT)
+		do_input(alias, id->ffbit, 0, SND_MAX);
+	sprintf(alias + strlen(alias), "w*");
+	if (id->flags&INPUT_DEVICE_ID_MATCH_SWBIT)
+		do_input(alias, id->swbit, 0, SW_MAX);
+	return 1;
+}
+
 /* Ignore any prefix, eg. v850 prepends _ */
 static inline int sym_is(const char *symbol, const char *name)
 {
@@ -453,7 +511,9 @@ void handle_moddevtable(struct module *m
 	else if (sym_is(symname, "__mod_i2c_device_table"))
 		do_table(symval, sym->st_size, sizeof(struct i2c_device_id),
 			 do_i2c_entry, mod);
-
+	else if (sym_is(symname, "__mod_input_device_table"))
+		do_table(symval, sym->st_size, sizeof(struct input_device_id),
+			 do_input_entry, mod);
 }
 
 /* Now add out buffered information to the generated C source */

-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

Re: Two module-init-

[Kay Sievers]

On Sat, Dec 03, 2005 at 10:59:48AM +1100, Rusty Russell wrote:
> On Fri, 2005-12-02 at 09:01 +0000, Scott James Remnant wrote:
> > On Fri, 2005-12-02 at 11:12 +1100, Rusty Russell wrote:
> > 
> > > On Wed, 2005-11-30 at 14:09 +0000, Scott James Remnant wrote:
> > > > Hi Rusty,
> > > > 
> > > > Attached are two patches to module-init-tools from Ubuntu.
> > > > 
> > > > The first (input_table_size) is a catch-up with 2.6.15, it's adding an
> > > > extra field to the input_device_id struct; m-u-t needs updating to be
> > > > able to read the modules correctly.
> > > 
> > > Unfortunately, it's not that simple.  Your patch will break previous
> > > kernels, which have a smaller structure.  I've had the discussion years
> > > ago with the input people on using module aliases, and it's not entirely
> > > trivial.  I will prepare another patch, however.
> > > 
> > Are the modules.*map files intended to be deprecated entirely in favour
> > of aliases?  The problem this patch fixed was that the parser couldn't
> > read the tables, so produced invalid output for the modules (ie. an
> > empty modules.inputmap).
> 
> Yes, but now it will produce a bad modules.inputmap for previous
> kernels.
> 
> Here's the patch for modalias support for input classes.  It uses
> comma-separated numbers, and doesn't describe all the potential keys (no
> module currently cares, and that would make the strings huge).  The
> changes to input.h are to move the definitions needed by file2alias
> outside __KERNEL__.  I chose not to move those definitions to
> mod_devicetable.h, because there are so many that it might break compile
> of something else in the kernel.
> 
> The rest is fairly straightforward.

Nice! Seems the last user of the map files is gone now.
Here is the MODALIAS for the event environment.



From: Kay Sievers <kay.sievers@suse.de>

input: add MODALIAS to the event environment

Signed-off-by: Kay Sievers <kay.sievers@suse.de>
---

diff --git a/drivers/input/input.c b/drivers/input/input.c
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -528,40 +528,56 @@ INPUT_DEV_STRING_ATTR_SHOW(name);
 INPUT_DEV_STRING_ATTR_SHOW(phys);
 INPUT_DEV_STRING_ATTR_SHOW(uniq);
 
-static int print_modalias_bits(char *buf, char prefix, unsigned long *arr,
+static int print_modalias_bits(char *buf, int size, char prefix, unsigned long *arr,
 			       unsigned int min, unsigned int max)
 {
 	int len, i;
 
-	len = sprintf(buf, "%c", prefix);
+	len = snprintf(buf, size, "%c", prefix);
 	for (i = min; i < max; i++)
 		if (arr[LONG(i)] & BIT(i))
-			len += sprintf(buf+len, "%X,", i);
+			len += snprintf(buf + len, size - len, "%X,", i);
 	return len;
 }
-	
-static ssize_t input_dev_show_modalias(struct class_device *dev, char *buf)
+
+static int print_modalias(char *buf, int size, struct input_dev *id)
 {
-	struct input_dev *id = to_input_dev(dev);
-	ssize_t len = 0;
+	int len;
 
-	len += sprintf(buf+len, "input:b%04Xv%04Xp%04Xe%04X-",
+	len = snprintf(buf, size, "input:b%04Xv%04Xp%04Xe%04X-",
 		       id->id.bustype,
 		       id->id.vendor,
 		       id->id.product,
 		       id->id.version);
 
-	len += print_modalias_bits(buf+len, 'e', id->evbit, 0, EV_MAX);
-	len += print_modalias_bits(buf+len, 'k', id->keybit,
+	len += print_modalias_bits(buf + len, size - len, 'e', id->evbit,
+				   0, EV_MAX);
+	len += print_modalias_bits(buf + len, size - len, 'k', id->keybit,
 				   KEY_MIN_INTERESTING, KEY_MAX);
-	len += print_modalias_bits(buf+len, 'r', id->relbit, 0, REL_MAX);
-	len += print_modalias_bits(buf+len, 'a', id->absbit, 0, ABS_MAX);
-	len += print_modalias_bits(buf+len, 'm', id->mscbit, 0, MSC_MAX);
-	len += print_modalias_bits(buf+len, 'l', id->ledbit, 0, LED_MAX);
-	len += print_modalias_bits(buf+len, 's', id->sndbit, 0, SND_MAX);
-	len += print_modalias_bits(buf+len, 'f', id->ffbit, 0, FF_MAX);
-	len += print_modalias_bits(buf+len, 'w', id->swbit, 0, SW_MAX);
-	len += sprintf(buf+len, "\n");
+	len += print_modalias_bits(buf + len, size - len, 'r', id->relbit,
+				   0, REL_MAX);
+	len += print_modalias_bits(buf + len, size - len, 'a', id->absbit,
+				   0, ABS_MAX);
+	len += print_modalias_bits(buf + len, size - len, 'm', id->mscbit,
+				   0, MSC_MAX);
+	len += print_modalias_bits(buf + len, size - len, 'l', id->ledbit,
+				   0, LED_MAX);
+	len += print_modalias_bits(buf + len, size - len, 's', id->sndbit,
+				   0, SND_MAX);
+	len += print_modalias_bits(buf + len, size - len, 'f', id->ffbit,
+				   0, FF_MAX);
+	len += print_modalias_bits(buf + len, size - len, 'w', id->swbit,
+				   0, SW_MAX);
+	return len;
+}
+
+static ssize_t input_dev_show_modalias(struct class_device *dev, char *buf)
+{
+	struct input_dev *id = to_input_dev(dev);
+	ssize_t len;
+
+	len = print_modalias(buf, PAGE_SIZE, id);
+	len += snprintf(buf + len, PAGE_SIZE-len, "\n");
 	return len;
 }
 static CLASS_DEVICE_ATTR(modalias, S_IRUGO, input_dev_show_modalias, NULL);
@@ -728,8 +744,11 @@ static int input_dev_uevent(struct class
 	if (test_bit(EV_SW, dev->evbit))
 		INPUT_ADD_HOTPLUG_BM_VAR("SW=", dev->swbit, SW_MAX);
 
-	envp[i] = NULL;
+	envp[i++] = buffer + len;
+	len += snprintf(buffer + len, buffer_size - len, "MODALIAS=");
+	len += print_modalias(buffer + len, buffer_size - len, dev) + 1;
 
+	envp[i] = NULL;
 	return 0;
 }
 

Re: Two module-init-

[Dmitry Torokhov]

On Thursday 01 December 2005 19:12, Rusty Russell wrote:
> Meanwhile, as noone seems to use swbit in struct input_device_id,
> perhaps we can remove it for 2.6.15?
> 

Please take a look at drivers/input/keyboard/corgikbd.c

-- 
Dmitry

Re: Two module-init-

[Dmitry Torokhov]

On Friday 02 December 2005 23:19, Dmitry Torokhov wrote:
> On Thursday 01 December 2005 19:12, Rusty Russell wrote:
> > Meanwhile, as noone seems to use swbit in struct input_device_id,
> > perhaps we can remove it for 2.6.15?
> > 
> 
> Please take a look at drivers/input/keyboard/corgikbd.c
> 

What I meant we do use EV_SW in the drivers and so it sould be part
of input_device_id. Nobody uses ffbit or sndbit either and still
they are present...

-- 
Dmitry

Re: Two module-init-

[Rusty Russell]

On Fri, 2005-12-02 at 23:28 -0500, Dmitry Torokhov wrote:
> On Friday 02 December 2005 23:19, Dmitry Torokhov wrote:
> > On Thursday 01 December 2005 19:12, Rusty Russell wrote:
> > > Meanwhile, as noone seems to use swbit in struct input_device_id,
> > > perhaps we can remove it for 2.6.15?
> > > 
> > 
> > Please take a look at drivers/input/keyboard/corgikbd.c
> > 
> 
> What I meant we do use EV_SW in the drivers and so it sould be part
> of input_device_id. Nobody uses ffbit or sndbit either and still
> they are present...

Sure.  BUT it will break current users.  I'm suggesting we jerk that
field out for 2.6.15, and reintroduce it for >= 2.6.16, when we can (1)
ensure everyone has a fixed module-init tools, or (2) make sure everyone
is using the module alias stuff, or both.

It seems the simplest solution, surely?
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

Re: Two module-init-

[Richard Purdie]

On Sun, 2005-12-04 at 21:24 +1100, Rusty Russell wrote:
> On Fri, 2005-12-02 at 23:28 -0500, Dmitry Torokhov wrote:
> > On Friday 02 December 2005 23:19, Dmitry Torokhov wrote:
> > > On Thursday 01 December 2005 19:12, Rusty Russell wrote:
> > > > Meanwhile, as noone seems to use swbit in struct input_device_id,
> > > > perhaps we can remove it for 2.6.15?
> > > > 
> > > 
> > > Please take a look at drivers/input/keyboard/corgikbd.c
> > > 
> > 
> > What I meant we do use EV_SW in the drivers and so it sould be part
> > of input_device_id. Nobody uses ffbit or sndbit either and still
> > they are present...
> 
> Sure.  BUT it will break current users.  I'm suggesting we jerk that
> field out for 2.6.15, and reintroduce it for >= 2.6.16, when we can (1)
> ensure everyone has a fixed module-init tools, or (2) make sure everyone
> is using the module alias stuff, or both.
> 
> It seems the simplest solution, surely?

The two users of EV_SW I'm aware of are corgikbd.c and spitzkbd.c.
Speaking as the maintainer of the kernel builds for the main users of
Zaurus 2.6 kernels, I can safely say that those two drivers are always
likely to be compiled into a kernel (not modules) and therefore this is
unlikely to upset anyone from a technical point of view. I keep out of
politics ;-)

Richard

Re: Two module-init-

[Dmitry Torokhov]

On 12/4/05, Rusty Russell <rusty@rustcorp.com.au> wrote:
> On Fri, 2005-12-02 at 23:28 -0500, Dmitry Torokhov wrote:
> > On Friday 02 December 2005 23:19, Dmitry Torokhov wrote:
> > > On Thursday 01 December 2005 19:12, Rusty Russell wrote:
> > > > Meanwhile, as noone seems to use swbit in struct input_device_id,
> > > > perhaps we can remove it for 2.6.15?
> > > >
> > >
> > > Please take a look at drivers/input/keyboard/corgikbd.c
> > >
> >
> > What I meant we do use EV_SW in the drivers and so it sould be part
> > of input_device_id. Nobody uses ffbit or sndbit either and still
> > they are present...
>
> Sure.  BUT it will break current users.  I'm suggesting we jerk that
> field out for 2.6.15, and reintroduce it for >= 2.6.16, when we can (1)
> ensure everyone has a fixed module-init tools, or (2) make sure everyone
> is using the module alias stuff, or both.
>
> It seems the simplest solution, surely?

Is there real users that are broken? It looks like most distros either
have mousedev and evdev compiled in or load them unconditionally. So
the simpliest is just probably get MODALIAS stuff in 2.6.16 and that's
it. It's not like swbit is new in 2.6.15, it was there since 2.6.14
was opened.

--
Dmitry

Re: Two module-init-

[Rusty Russell]

On Mon, 2005-12-05 at 16:47 -0500, Dmitry Torokhov wrote:
> It's not like swbit is new in 2.6.15, it was there since 2.6.14
> was opened.

Err, yeah, good point.  I had assumed this was new in 2.6.14.  Since
we've only seen reports now, I'll assume it's low priority and we can
wait until 2.6.16.

I have a cunning plan to fix module-init-tools in the meantime; expect a
release if it works out...

Thanks all!
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman