From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Sat, 20 Jan 2001 20:55:50 +0000 Subject: Re: Roadmap to restoring working usb module autoloading? Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org > From: Adam J. Richter > Sent: Saturday, January 20, 2001 5:32 AM > > I am concerned that the situation with usb module autoloading > seems to be deadlocked With regards to getting kernel and modutils talking again, in production releases of both. > 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. Yep. Milestones of note include "works as well as the prerelease", and "bugs noted in prerelease are now fixed". > 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. Thanks. This should get rid of the "doesn't work with usbutils" set of problems. > 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 It was using structure size before, which was clearly not going to work in cases like this (same size, fields rearranged). I don't know that the (optional?) kernel version string was being considered. > 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. I'm not sure we'd want to encourage or support that. It'd effectively be a kernel fork. > These are issues that have occurred to me while > wondering why the changes have not been integrated yet. They > are just second guessing, though. I'm concerned that's most of what we have to go by. Another thought is that it was a recognition that the failure modes related to the netdevice stuff (see Andrew's recent post) were a bit too severe to push on other parts of hotplug without having that fixed first. Complete system hangs are not polite in "production" kernels. > 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): I'm really concerned about that second-guessing issue. That's not the way to achieve consistent forward motion, at least in my book, and likely contributed to the original 2.4.0 problem. > 3. Likewise, the rest of USB userland support scripts should > be updated. I do not use these. Perhaps david-b could comment on this. They've been pretty much up-to-date for a few weeks, and won't care so long as the "match_flags" shows up in the first field of the text output. I will note those scripts currently ignore the match_flags field, since bitfields are just nasty to deal with in shell scripts (fixable). And they're expecting only "new style" output from modutils (also fixable). Anyone wanting to hotplug with prerelease or 2.4.0-test kernels can use "usbmodules", or older scripts ... anyone wanting a different USB agent (in C?), feel free to provide one. > 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 For my part, I'm wanting to hear something from Linus. We're now in decent shape (matching functionality in the prerelease, unfortunately including that netdevice problem) if he'd merge that patch from Keith. - Dave > 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