On Wed, Dec 13, 2000 at 01:51:36PM -0800, Adam J. Richter wrote:
> 1. The kernel lacks regular expression support, so these
Yes, I was under the impression that the regexp parsing would be in
user-space by the program you proposed. Regexp in the kernel is never
going to happen!
> what matched. Are there currently any parport
> clients that would find it useful to differentiate based
> on which of more than one IEEE-1284 pattern matched
> (e.g., "MDL:GadgetVersion1" versus "MDL:GadgetVersion2")?
Don't know.
> 3. regexps are great at expressing all many kinds of patterns, but
> they are lousy at concisely expressing the idea that four
> different substrings must all be found, but that they can
> occur in any order. Is there a standard for
> the order in which the different fields in the IEEE-1284
> device string? Even if a few device violate that standard,
No.
> 5. For simplicity, I would prefer to keep the matching case
> sensitive. Are there any real devices that actually could
> be matched more easily with case insensitive matching?
The key names (like class, etc) are not necessarily upper case. If
you know _exactly_ what your device says you can get away with
it. (also CLASS === CLS etc).
> 6. Currently, my plan for doing the matching "right" would
> be to have struct portport_device_id look like this:
>
> struct parport_device_id {
> char *pattern;
> };
>
> and each pattern would be a semicolon separated list of glob
> patterns, which could be matched in any order. For example,
>
> "CLS:PRINTER;MFG:Hew*"
>
> would match "MFG:Hewlett Packard;CLS:PRINTER".
This is good. The matching utility would have to know about
CLS/CLASS/cls etc, and would probably also need to strip leading and
trailing blanks.
The code looks good although I'm not so keen on casting a string to a
parport_device_id*, I'd rather have an array of strings like your
my_camera_ids.
Tim.
*/
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Wed Dec 13 2000 - 18:01:54 EST