(Linus, please respond!) Re: Roadmap to restoring working usb module

(Linus, please respond!) Re: Roadmap to restoring working usb module

[Miles Lane]

"Adam J. Richter" wrote:
> 
>         I am concerned that the situation with usb module autoloading
> seems to be deadlocked and so I want to propose a roadmap for
> getting to the point where usb module autoloading works when a
> user installs the latest versions of everything and does not
> make any additional modifications.

I agree that we are deadlocked.  However, I think we should continue
to try to get Linus to accept Kieth's patch, at least until he gives
us a solid reason for rejecting the patch.

My only conjecture is that he simply thinks hotplugging is "new"
functionality that is not in active use, and that, therefore, fixing 
it should wait until the 2.4.0 series leaves "bugfix mode."

If any of you have enough leverage with Linus to get him to tell us 
why the patch hasn't been included, please do so.

Thanks,
	Miles

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (Linus, please respond!) Re: Roadmap to restoring working usb

[Linus Torvalds]

On Sat, 20 Jan 2001, Miles Lane wrote:
> 
> I agree that we are deadlocked.  However, I think we should continue
> to try to get Linus to accept Kieth's patch, at least until he gives
> us a solid reason for rejecting the patch.

I have absolutely no idea of even what patch you are talking about, so
discussing it is a total waste of time. As far as I am concerned, what is
in the current 2.4.0 tree and pre-patches, is what 2.4.1 will be.

I care absolutely _zilch_ about roadmaps etc crap. I want to have a
totally overriding reason for specific patches (and they'd better be small
to be even considered), and I'm not going to bother even answering
"discussion" as this has been for the last week.

		Linus


_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (Linus, please respond!) Re: Roadmap to restoring working usb

[Linus Torvalds]

On Sun, 21 Jan 2001, Keith Owens wrote:
> 
> For the record.  The addition of match_flags in struct usb_device_id
> highlighted an ABI problem between the kernel and depmod.  It proved
> that relying on the table size to detect format changes was a bad
> idea(TM), adding a field will not always change the table size.  The
> table version numbers added in my patch (appended) are _required_ for
> depmod to reliably detect that a format has changed.

I'd much rather just have the 2.4.0 behaviour, and no versioning. Tell
people that 2.4.0-test kernels won't work. They'll notice on their own.

This problem won't be a problem in a few months if we just kill it _now_,
rather than try to work around it.

		Linus


_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (Linus, please respond!) Re: Roadmap to restoring working usb module

[Miles Lane]

Keith Owens wrote:

<snip>

> Fine, until the next time any of the table formats have to be changed.
> The version number on the kernel tables that depmod reads are there for
> future changes, not just for the current usb mess.  Without a version
> number we will have exactly the same problems on the next ABI change.
> 
> Whether we should support the 2.4.0-test format for usb is a separate
> question and has nothing to do with whether depmod needs version
> numbers at all.  My patch is to future proof the kernel/depmod interface.

Is there a way to rework modutils and your patch so that hotplugging
can work without introducing the version numbers that Linus doesn't
want to introduce?  Then, you and he could settle the version tracking
resolution later without holding up support for /sbin/hotplug.

Thanks,
	Miles

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (Linus, please respond!) Re: Roadmap to restoring working

[Linus Torvalds]

On Sat, 20 Jan 2001, Miles Lane wrote:
> 
> I have attached the patch.

Ok, this is the same I sw in my later email.

I'm not applying stuff like this. I try very hard indeed to avoid
interface changes during stable kernel releases, and there really has to
be some overriding concern like "it is fundamentally broken and you cannot
make it work" or "it oopses".

The only reason for this patch seems to be that people want to distinguish
between pre-kernels and the final thing, and I just don't think that is
overriding enough. In fact, I personally think it's not even interesting.

I can easily apply a patch that just increases the documentation changes
version number for modutils. The fact that such modutils binaries won't
work with pre-2.4.0 kernels is not even on my radar screen, quite frankly.
There isn't even an installed base of people using it, and I don't think
anybody of the developers using it are still using pre-kernels. In short,
I see absolutely no reason for even trying to maintain any backwards
compatibility in this area.

		Linus


_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (Linus, please respond!) Re: Roadmap to restoring working usb

[Linus Torvalds]

On Sun, 21 Jan 2001, Keith Owens wrote:
> 
> Fine, until the next time any of the table formats have to be changed.

Oh, agreed. We want to fix this eventually, but I really feel that it's a
2.5.x issue.

It turns into a 2.4.x issue only if somebody can show that 2.4.0 _cannot_
work. Which is not the case, as far as I know. 

I certainly agree that the unintentional table format change was a very
unfortunate thing. It was not intended to have the consequences it had,
and obviously nobody even thought about it. As such, comments etc should
probably be updated, but I don't want interface changes until they
absolutely _have_ to happen.

(Side note: when 2.5.x does do this and adds proper versioning, and it is
found to be good, and the improved modutils spread out, we may end up
back-porting the stuff later. And I would certainly not mind modutils
already getting the hooks in it to support versioning - I do see that it's
a good idea. It' sjust that I'd rather not make what I consider to be just
cleanups when they actually change behaviour).

		Linus


_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (Linus, please respond!) Re: Roadmap to restoring working

[David Brownell]

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

The modutils patch I sent with my bugreport did exactly that.

It's attached here, against depmod 2.4.0 ... should give the
same "modules.usbmap" output depmod 2.4.1 does.  Not expected
to work on prerelease/test kernel modules.



----- Original Message -----
From: Miles Lane <miles@megapathdsl.net>
To: Keith Owens <kaos@ocs.com.au>
Cc: Linus Torvalds <torvalds@transmeta.com>; <linux-hotplug-devel@lists.sourceforge.net>
Sent: Saturday, January 20, 2001 9:24 PM
Subject: Re: (Linus, please respond!) Re: Roadmap to restoring working usbmodule
autoloading?


> Keith Owens wrote:
>
> <snip>
>
> > Fine, until the next time any of the table formats have to be changed.
> > The version number on the kernel tables that depmod reads are there for
> > future changes, not just for the current usb mess.  Without a version
> > number we will have exactly the same problems on the next ABI change.
> >
> > Whether we should support the 2.4.0-test format for usb is a separate
> > question and has nothing to do with whether depmod needs version
> > numbers at all.  My patch is to future proof the kernel/depmod interface.
>
> Is there a way to rework modutils and your patch so that hotplugging
> can work without introducing the version numbers that Linus doesn't
> want to introduce?  Then, you and he could settle the version tracking
> resolution later without holding up support for /sbin/hotplug.
>
> Thanks,
> Miles
>
> _______________________________________________
> Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
> Linux-hotplug-devel@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

[-- Attachment #2: depmod.patch --]
[-- Type: application/octet-stream, Size: 1848 bytes --]

--- depmod-dist.c	Thu Jan  4 19:18:18 2001
+++ depmod.c	Thu Jan  4 19:23:04 2001
@@ -101,7 +101,7 @@
 	} devs[ISAPNP_CARD_DEVS];	/* logical devices */
 };
 
-/* Extracted from 2.4.0-test10-pre3 + David Brownell usb-device_id patch 2 */
+/* Extracted from 2.4.0 */
 #ifndef __u16
 #define __u16 u_int16_t
 #endif
@@ -121,6 +121,11 @@
  * Init the fields you care about; zeroes are not used in comparisons.
  */
 struct usb_device_id {
+	/* This bitmask is used to determine which of the following fields
+	 * are to be used for matching.
+	 */
+	__u16		match_flags;
+
 	/*
 	 * vendor/product codes are checked, if vendor is nonzero
 	 * Range is for device revision (bcdDevice), inclusive;
@@ -1075,7 +1080,7 @@
 	}
 
 	ptmod = modules;
-	fprintf(usbmap, "# usb module         idVendor idProduct bcdDevice_lo bcdDevice_hi"
+	fprintf(usbmap, "# usb module         match_flags idVendor idProduct bcdDevice_lo bcdDevice_hi"
 		" bDeviceClass bDeviceSubClass bDeviceProtocol bInterfaceClass bInterfaceSubClass"
 		" bInterfaceProtocol driver_info\n");
 	for (i = 0; i < n_modules; i++, ptmod++) {
@@ -1084,10 +1089,11 @@
 		if (!ptmod->n_usb_device)
 			continue;
 		for (j = 0; j < ptmod->n_usb_device; j++, usb_device++) {
-			fprintf(usbmap, "%-20s 0x%0*x   0x%0*x    0x%0*x       0x%0*x       "
+			fprintf(usbmap, "%-20s 0x%0*x 0x%0*x   0x%0*x    0x%0*x       0x%0*x       "
 				"0x%0*x         0x%0*x            0x%0*x            0x%0*x            0x%0*x            "
 				"0x%0*x            0x%0*" tgt_long_fmt "x\n",
 				shortname(ptmod->name),
+				2*sizeof(usb_device->match_flags), usb_device->match_flags,
 				2*sizeof(usb_device->idVendor), usb_device->idVendor,
 				2*sizeof(usb_device->idProduct), usb_device->idProduct,
 				2*sizeof(usb_device->bcdDevice_lo), usb_device->bcdDevice_lo,

Re: (Linus, please respond!) Re: Roadmap to restoring working usb module

[Miles Lane]

Keith Owens wrote:

> Since usb is the only table that has multiple versions at the 
> moment, it is the only one to worry about.  Version 1 usb is 
> 2.4.0-prerelease and earlier, this works with all modutils.  
> I want to support this earlier version because I know of at 
> least one group that is still using 2.4.0-test12 for IA64 
> hardware reasons. 

I would like to know more about this.  Does anyone have specifics
about this IA64 issue?  Kieth, would you research this?  

David Brownell has already dropped all support for the 
pre-2.4.0 versions of hotplugging.  People who want to use 
the USB backport can simply continue using the usb.rc and USB 
policy scripts, can't they?

	Miles

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel