All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: (Linus, please respond!) Re: Roadmap to restoring working
Date: Sun, 21 Jan 2001 05:42:50 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-98005550814296@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-98004206800249@msgid-missing>

[-- 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,

  parent reply	other threads:[~2001-01-21  5:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-21  1:57 (Linus, please respond!) Re: Roadmap to restoring working usb module Miles Lane
2001-01-21  4:36 ` (Linus, please respond!) Re: Roadmap to restoring working usb Linus Torvalds
2001-01-21  4:39 ` Linus Torvalds
2001-01-21  5:24 ` (Linus, please respond!) Re: Roadmap to restoring working usb module Miles Lane
2001-01-21  5:26 ` (Linus, please respond!) Re: Roadmap to restoring working Linus Torvalds
2001-01-21  5:31 ` (Linus, please respond!) Re: Roadmap to restoring working usb Linus Torvalds
2001-01-21  5:42 ` David Brownell [this message]
2001-01-21  7:54 ` (Linus, please respond!) Re: Roadmap to restoring working usb module Miles Lane

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-hotplug-98005550814296@msgid-missing \
    --to=david-b@pacbell.net \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.