From: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: Matching semantics for version numbers....
Date: Wed, 21 Mar 2001 18:54:53 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-98520095000979@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-98512282728951@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]
On Tue, Mar 20, 2001 at 10:12:09PM -0800, David Brownell wrote:
> Hi Matt,
>
> Two comments come to mind:
>
> (1) Is it correct that changing this would involve no more than:
>
> * Linux 2.4.? kernel updates:
> - drivers/usb/usb.c ... usb_match_id()
> - drivers/usb/ibmcam.c ... uses range matching
I'm not certain if this range-matching is done correctly for < > or if it
thinks <= and >=, but assuming it's "working" now, yes, it would need
changing.
> - drivers/usb/storage/unusual_devs.h ... lots of ranges
This wouldn't need updating -- it's actually improperly coded right now
with the assumption of <= and >= (which was how my custom matching code
worked).
> * Hotplug scripts
> * "usbmodules"
I'm not sure what you mean by this item.
> * No spec/documentation (yet)
Other than my comments above, yes, that should be all the changes.
> Distributions would need to get all those updates at once;
> I don't know how much of a problem that'd be, except
> that if there's no coordination then it'll be painful. If it
> happens, this should all be ready at the same time. (Not
> like the original match_flags patch ... though goofing this
> up would break less, since "modutils" will still work.)
AFAICT, yes. Having one part of the patch (assuming the 2 kernel files
count as one "part") doesn't break anything.
> (2) For some reason my preference in this area would
> be to use "low <= value < high" range specs rather the
> current "low < value < high" or "low <= value <= high".
>
> That's just a better match to how I normally think about
> such ranges -- not a huge deal, but it seems like Jeff
> Ozvold had a similar thought. So maybe I'm not alone
> in thinking about those bcd version codes that way.
Someone mentioned this to me in a private e-mail... it seems reasonable, as
then range checks can be 0.00 -- 3.00, and 3.00 -- 9.99 with no overlap.
Tho, it _must_ be well documented that the low and high parameters are
matched slightly differently.
Matt
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
Ye gods! I have feet??!
-- Dust Puppy
User Friendly, 12/4/1997
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
next prev parent reply other threads:[~2001-03-21 18:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-20 21:12 Matching semantics for version numbers Matthew Dharm
2001-03-21 6:12 ` David Brownell
2001-03-21 18:54 ` Matthew Dharm [this message]
2001-03-22 19:23 ` David Brownell
2001-03-22 19:50 ` Matthew Dharm
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-98520095000979@msgid-missing \
--to=mdharm-usb@one-eyed-alien.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.