Last night, I mentioned that I had a very preliminary
implementation of parport MODULE_DEVICE_TABLE support. I am
included all of the relevant software in this email, and I
would like to get some feedback on how to do it right.
Under my very preliminary scheme, struct parport_device_id
is really just a char, and the array of parport_device_id's is really
just a string, which is a regular expression that parptmodules uses to
match the printer device ID. This has a few drawbacks:
1. The kernel lacks regular expression support, so these
strings cannot be reliably used within the kernel
itself to support ID matching. It would be better if
the data structure used in matching could be used within
the kernel to do the same matching rather than have that
knowledge duplicated in each parport client's probe routine.
2. The current scheme supports only one string. Although
any combination of regular expressions can be combined into
a single regular expression, it might be helpful to have
an array of strings so that the kernel code could know
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")?
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,
if we can rely on most devices following it, it probably
will be simpler not to bother with any-order parsing,
and just have the few non-conformant device get matched
by having multiple ID strings.
4. Any objections to the names modules.parptmap and
parptmodules (as opposed to modules.parportmap and
parportmodules, I guess)?
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?
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".
At some point, it would be possible to add a probe interface
like the USB and new style PCI and ISAPnP interfaces, which
would actually pass a pointer to the pattern that caused
the match, so that drivers could have declarations like:
struct parport_device_id my_camera_ids[] = {
{ "CLS:DIGICAM;MFG:SomeCompany;MDL:Model 500 B&W" },
{ "CLS:DIGICAM;MFG:SomeCompany;MDL:Model 500 Color" },
{ "CLS:DIGICAM;MFG:SomeCompany;MDL:Model 800 Color" },
NULL
};
int camera_flags[] = {
FLAG_MODEL_500,
FLAG_MODEL_500 | FLAG_COLOR,
FLAG_MODEL_800 | FLAG_COLOR
};
int
mycam_probe(struct pardevice *dev, struct port_device_id *id) {
int flags = camera_flags[id - my_camera_ids];
...and then take different action based on which ID matched.
Comments?
Anyhow, on to the code snapshot.
I have included the changes that I made last night to add parport
MODULE_DEVICE_TABLE support. Be warned that this is probably not
the final format that parport_device_id tables will have. I am
including three attachments to this email:
kernel.diffs - Simple patch to include/linux/parport.h and
drivers/char/lp.c to show how to declare
a MODULE_DEVICE_TABLE under this scheme.
I think it adds about three lines to each file.
modutils.diffs - Patch to depmod (in modutils-2.3.22)
to make it generate /lib/modules/<version>/modules.parptmap
under this scheme.
parptmodule.c - A simple user level program that lists the
modules that patch the ieee1284 string provided as
the program's only argument. For example, try
"parptmodules 'blahblah;CLS:PRINTER;blahblah' after
you have installed the updated lp.c and modutils.
Under this scheme boot time autoloading of the relevant modules
could be implemented by adding something like to following to
/etc/modules.conf, which I have not tried (probably this need to
adjusted to quote the "$"'s for modprobe, but it should illustrate
my point):
after parport
for idfile in /proc/sys/dev/parport/parport*/autoprobe* ; do \
for module in $(parptmodules "$(cat $idfile)" ) ; do \
modprobe $module ; \
done ; \
done
#Also do USB? (assumes USB printers are in /dev/usb/printer/,
#and uses usb-printer-id program to extract IEEE-1284 data.
after printer
for printerfile in /dev/usb/printer/* ; do \
for module in $(parptmodules $(usb-printer-id $printerfile)) ; do \
modprobe $module ; \
done ; \
done
-- 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 - 16:54:28 EST