Re: [PARPORT] autoloading drivers based on ieee1284 device ID changes?

From: Adam J. Richter (
Date: Tue Dec 12 2000 - 22:15:05 EST

  • Next message: Adam J. Richter: "Re: [PARPORT] autoloading drivers based on ieee1284 device ID changes?"

            I spent a little time today thinking about implementing a
    uniform ioctl to extract the ieee1284 device ID data, but soon
    realized that there is no device to do the ioctl on if no particular
    parport client device driver has been loaded. So, I guess I'll
    just live with the current /proc/sys/dev/parport/parportN/autoprobe
    files (although I did end up generating a patch to clean up
    ieee1284 device ID extraction in usb/printer.c, so the exercise was

            Anyhow, here are some things that I would like to do, and
    I would appreciate comments on them, as I would like to get the
    kernel changes into Linus's releases if possible.

            1. Change the current sysconf ieee1284 printer ID interface
    to actually read the data when requested rather than storing it.

            2. (Probably simultaneous with #1). Gut the printer ID
    parsing code and have the interface just return the raw ID string.
    As far as I can tell, nobody uses the parsed code. The parsing
    could easily be done by a simple user level utility, and it just
    makes ID string matching harder.

            3. Define a MODULE_DEVICE_TABLE format for parport clients.
    I think the format would simply be a null terminated string consisting
    of regular expressions that a user level program could match to
    autoload the module. For example, lp.c might have a declaration like

    static char __initdata printer_ids[] =

    MODULE_DEVICE_TABLE(parport, printer_ids);

            4. Submit a patch to modutils so that depmod will generate
    /lib/modules/<version>/modules.parptmap from any parpot
    MODULE_DEVICE_TABLE entries. In this way, people will be able
    to write new parport drivers and have their ID information work
    without having to coordinate with the maintainers of some central
    file of ID's.

            5. Write "parptmodules", a simple application to implement the autoloading
    from this information by reading /lib/modules/<version>/modules.parportmap
    and /proc/sys/parport/ and printing the list of modules to load.
    That way, Linux distributions would just do something like this in
    some rc script:

            modprobe parport
            for module in off $(parptmodules) ; do
                    modprobe -s -k $module

            That would be enough to ensure that whatever modules were
    needed would be loaded at boot time.

            6. Add MODULE_DEVICE_TABLE entries to the current
    users of partport_register_device if people will send me ID
    strings (or they can the entries themselves):


            7. One of these days, I would like to put together a mapping
    of ieee1284 device ID's for printers to /etc/printcap and ghostscript
    settings that would be regenerated every time a print job starts
    printing (so you could switch printers), but that largely a separate

            Comments? Suggestions?

    Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104 \ / 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: --
    -- with the single word "unsubscribe" in the body of the message. --

    This archive was generated by hypermail 2b29 : Tue Dec 12 2000 - 22:24:44 EST