Re: [PARPORT] Re: PATCH: parport_device_id support, "version 2.1"

From: Adam J. Richter (
Date: Thu Jan 18 2001 - 19:27:49 EST

  • Next message: Guido Milanese: "Re: [PARPORT] Imation LS 120 on parallel port"

    >> = Adam Richter
    > = Tim Waugh

    >> -extern ssize_t parport_device_id (int devnum, char *buffer, size_t len);
    >> +extern ssize_t parport_get_id (int devnum, char **buf_out);

    >This is just unnecessary, as well as changing the documented interface
    >(Documentation/DocBook). This is worse than the autoprobe thing!

            The name change is because the MODULE_DEVICE_TABLE macro
    in include/linux/module.h requires that if the type of table is
    called "parport", then the ID structure must be named parport_device_id
    and having a procedure of the same name makes it hard to grep for
    either of them and would break a module that uses C++.

            Allocating the string on the fly greatly simplifies the
    code in a couple of places and also allows it to handle strings
    longer than the size that you happened to preallocate.

            I have updated all of the places in the kernel that call
    these routines. Are there any currently existing modules outside
    of the kernel that use this interface and do not want to switch?

    >Please stop making gratuitous changes to interfaces, or the whole
    >thing will have to wait until 2.5.x.

    >> -extern int parport_find_device (const char *mfg, const char *mdl, int from);
    >> -extern int parport_find_class (parport_device_class cls, int from);

    >And again we have an interface change.

            Nothing in the stock kernel calls these routines anymore.
    Again, are there any modules outside of the kernel that actually
    use this interface and would not want to change?

            Putting back those routines means either putting back all of
    that unnecessary parsing code and the old data structures or
    writing new versions of these routines (which would probably be
    easier). It's not that much work, but it's probably more work
    than updating, say, two or three modules under development outside
    the kernel.

    >Adam, to do this now that we are in a stable branch, we have to only
    >_add_ bits.

            That has not been the case in the 2.2 branch (for
    example, 2.2.18 deleted the exported symbols machine_type, outswb,
    inswb, __arch_strlen_user, armidlist, armidindex, msgqueue_getnextmsg,
    msgqueue_peeknextmsg, loops_per_sec and rpc_do_call). Historically,
    Linus has been pretty sympathetic to code cleanups even at the cost
    of some interface changes, even in a stable branch (although not as
    much). Has Linus announced a new policy for 2.4?

            I am willing to write drivers/parport/parport_bloat.c
    (so that it will compile as a separate module that modprobe will
    automatically load if needed, and otherwise will not waste unswappable
    kernel memory), which would contain the legacy routines if you insist.
    I believe that they will never be called from any module that anyone
    ever ships.

    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 : Thu Jan 18 2001 - 19:29:21 EST