(Linus, please respond!) Re: Roadmap to restoring working usb module
Quoted 6 lines · Adam J. Richter
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Re: (Linus, please respond!) Re: Roadmap to restoring working usb
Quoted 4 lines · Miles Lane
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Re: (Linus, please respond!) Re: Roadmap to restoring working usb
In reply to Miles LaneQuoted 7 lines · Keith Owens
For the record. The addition of
match_flagsin structusb_device_idhighlighted 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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Keith Owens wrote:
<snip>
Quoted 8 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Re: (Linus, please respond!) Re: Roadmap to restoring working
In reply to Miles LaneQuoted 2 lines · Miles Lane
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Re: (Linus, please respond!) Re: Roadmap to restoring working usb
In reply to Miles LaneQuoted 2 lines · Keith Owens
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Re: (Linus, please respond!) Re: Roadmap to restoring working
In reply to Miles LaneThe 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 <[email protected]>
To: Keith Owens <[email protected]>
Cc: Linus Torvalds <[email protected]>; <[email protected]>
Sent: Saturday, January 20, 2001 9:24 PM
Subject: Re: (Linus, please respond!) Re: Roadmap to restoring working usbmodule autoloading?
Quoted 18 lines
Keith Owens wrote:
<snip>
Quoted 8 lines
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.
Quoted 7 lines
Thanks,
Miles_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
depmod.c renamed from depmod-dist.c +9 -3
@@ -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,
Quoted 6 lines · Keith Owens
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel