Linux Hotplug development
 help / color / mirror / Atom feed
* Roadmap to restoring working usb module autoloading?
@ 2001-01-20 13:32 Adam J. Richter
  2001-01-20 20:55 ` David Brownell
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: Adam J. Richter @ 2001-01-20 13:32 UTC (permalink / raw)
  To: linux-hotplug

	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.

	Here is my proposal:

	0. We agree that the endpoint of roadmap is not necessarily the
final destination that we are going to settle on, but rather a point
where everything works again and one that is closer to where we want
to be than before.

	1. I have just posted changes to usbmodules to recognize
both the old and new versions of modules.usbmap.  If the patches
work for everyone, then I would appreciate it if Thomas would make
a new release of usbutils that includes these changes.  There should
be no compatability problem with this.

	2. As I understand the situation, Linus and Alan have not
integrated Keith's module table version number patches after a number
of 2.4.1-pre releases.  The big advantage of using version numbers
for each ID structure instead of having depmod decide based on the
kernel version string is that you can update different components
of the kernel if yours is somewhat customized (e.g., imagine a 2.5.x
USB backport to 2.4).  However, this is currently defeated by an
error check in depmod which compalins "Modules have a mixture of
version ___ and version ___".   Also, integer version numbers that
increase by one create an ID allocation problem if somebody wants
to ship a modified device ID structure and a modutils that will
recognize it.  These are issues that have occurred to me while
wondering why the changes have not been integrated yet.  They
are just second guessing, though.  Someone should corner one of
them at LinuxWorld about it in any case.  I'm not sure what the other
advantages of the structure version numbers are supposed to be, but
I realize I'm probably not doing it justice in this paragraph.

	Although my understanding of the situtation is obviously
incomplete, I think the idea behind these version numbers was to
avoid version skew ("you have to upgrade the kernel if you upgrade
modutils").  However, that is preferable to nonfunction ("if you
upgrade the kernel, your modules won't work").  I'm also beginning
to think that there may be...maybe...some method to the madness of
not going with version numbers for the device ID tables, at least
enough so that I'm not sufficiently confident that Linus is wrong
that would I want to support an intransagence contest between
the standard kernels and the standard userland facilities for USB hot
plugging.  So, I propose that, for the meantime that modutils be changed
to accomodate Linus's kernels for now (I am willing to write these patches):

	2a. Back out the device ID structure version number code for now
and instead have a new modutils that supports only the new format for
usb_device_id.  module_device_id tables are not in 2.2 and the old
format was used only in 2.4.0-pre 2.4.0-test kernels, so everyone
is supposed to upgrade anyhow, especially if they're upgrading other
components on their system.

	2b. depmod wants usb_device_id.match_flags toward the end of
the structure and Linus's kernels put it toward the beginning.  I know
we had talked about rearranging the usb_device_id structure this way
to improve compatability.  Again, I propose having depmod accomodate
Linus's kernels.

	3. Likewise, the rest of USB userland support scripts should
be updated.  I do not use these.  Perhaps david-b could comment on this.

	If there are people in the midst of negotiating some other fix
with Linus and those who have his ear on this matter, I don't mean to
preempt their efforts.  But, I don't think that is what is going on.
I think everybody is waiting for some other event to break this impasse
and, in the meantime, USB hot plugging remains out of commission and
Linux will make a bad impression in this area with people who are trying
Linux because of the 2.4 hoopla.

	This does not mean that device ID version number are wrong
or should not get into Linus's kernels.  I just want the software
to continue to work with the current kernels in the meantime.

	Comments?  (Flames?)

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

_______________________________________________
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

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-01-21  3:21 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-01-20 13:32 Roadmap to restoring working usb module autoloading? Adam J. Richter
2001-01-20 20:55 ` David Brownell
2001-01-21  2:25 ` Adam J. Richter
2001-01-21  2:47 ` Keith Owens
2001-01-21  3:17 ` Adam J. Richter
2001-01-21  3:21 ` Keith Owens

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox