From: Keith Owens <kaos@ocs.com.au>
To: linux-hotplug@vger.kernel.org
Subject: Re: (Linus, please respond!) Re: Roadmap to restoring working usb module autoloading?
Date: Sun, 21 Jan 2001 06:06:16 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-98005719116230@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-98004518904180@msgid-missing>
On Sat, 20 Jan 2001 21:31:40 -0800 (PST),
Linus Torvalds <torvalds@transmeta.com> wrote:
>
>
>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.
Yes, I can change modutils 2.4.2 to only support the kernel 2.4.0
format for usb, but I do not see that as the main issue. To me, future
proofing is the main issue, to prevent the same mess again.
>(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).
If it is guaranteed that 2.4 will never change the formats of any of
the kernel/depmod tables, even when code is back ported from 2.5 to
2.4, then I agree with you that we do not need version numbers in 2.4.
But if there is any chance that the table formats will change in 2.4
then I want the version numbers added now to define the base support
level and to detect future problems before they occur.
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. Version 2 usb is for
2.4.0 with my kernel patch, this works with modutils 2.4.1 onwards.
Nothing supports the stock 2.4.0 kernel usb table format. Not because
I am being perverse but because adding the match_flags field to the
start of the structure really messes up modutils, it has to support two
completely different structure layouts. My patch moves match_flags to
the middle of the structure, replacing padding bytes and simplifying
modutils. This does not change kernel behaviour because nothing works
with the 2.4.0 usb table format, it is already broken.
Modutils and hotplug scripts are all ready for kernel 2.4.1, they just
needs the kernel patch. There is no change to kernel behaviour, the
patch fixes a bug.
_______________________________________________
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
next prev parent reply other threads:[~2001-01-21 6:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-21 2:36 (Linus, please respond!) Re: Roadmap to restoring working usb module autoloading? Keith Owens
2001-01-21 4:53 ` Keith Owens
2001-01-21 6:06 ` Keith Owens [this message]
2001-01-21 18:07 ` Johannes Erdfelt
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-98005719116230@msgid-missing \
--to=kaos@ocs.com.au \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).