>> = Adam Richter
> = Tim Waugh
>> 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.
Yes, that is the case. What I wanted was also to
eliminate duplication of this match information in kernel (i.e.,
have the kernel's matching also use the same table, as is done
with USB and the new style PCI and ISAPnP drivers).
Thanks for your answers to my other questions. They
help clarify things significantly.
>> 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.
Do any devices actually say "CLASS:" in their ID information?
>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.
Keith Owens emailed me a pointer to his MODULE_GENERIC_STRING
facility in modutils-2.3.22, which we could use if we were to
stick with the single string approach. However, I agree with you
and prefer a struct as described above, which will eliminate that
issue.
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."
-- 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:35:32 EST