[PARPORT] Questions and first pass at ieee1284 MODULE_DEVICE_TABLE support

From: Adam J. Richter (adam@yggdrasil.com)
Date: Wed Dec 13 2000 - 16:51:36 EST

  • Next message: Tim Waugh: "Re: [PARPORT] Questions and first pass at ieee1284 MODULE_DEVICE_TABLE support"

            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,


               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" },
               int camera_flags[] = {
                            FLAG_MODEL_500 | FLAG_COLOR,
                            FLAG_MODEL_800 | FLAG_COLOR

               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.


            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 ; \

    #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 ; \

    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