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

From: Adam J. Richter (
Date: Tue Jan 16 2001 - 17:24:51 EST

  • Next message: Tim Waugh: "Re: [PARPORT] PATCH: parport_device_id support, "version 2.0""

    Tim Waugh <> writes:

    >Now that 2.4.0 has actually been released, we kind of have an
    >obligation not to break /proc/sys/dev/parport/parport0/autoprobe
    >(again!). So, which of the changes you proposed would be okay I

            Which specific programs would the change to
    /proc/sys/dev/parport/parport0/autoprobe break? I am not aware of
    any that currently use this facility. If there are some, we can look
    at how easy it would be to change them to either use the new format
    or recognize and support both.

            If anything, now is a better time to make changes than
    before, since the "code freeze" is now over. I have delaying
    pushing to get these changes into Linus's kernels since the
    "prerelease" series. I do not think that developer who try
    to accomodate this process should be penalized. Otherwise, they
    will probably adjust their behavior accordingly in the future.

    >On Sun, Dec 24, 2000 at 07:01:20PM -0800, Adam J. Richter wrote:

    >> 1. A device's IEEE-1284.3 ID is now reread from hardware whenever
    >> the corresponding /proc/sys/dev/parport*/parport* file is read.
    >> However, the results are still stored in struct parport for now
    >> so that each driver does not have to requery each parallel port
    >> device. At some point in the future, parport probably should
    >> get a registration interface similar to the new PCI interface and
    >> the USB interface where some centrally-called routine does all
    >> of the matching and tells the drivers which devices they match.

    >This is probably okay, so long as it claims the port.

    >> 2. The printer ID parsing code has been replaced.
    >> /proc/sys/dev/parport*/parport* now return the IEEE-1284.3 string
    >> verbatim, including length bytes, whether they are correct or not.
    >> The only processing done is that a new line is added to the end.
    >> So, for example, you can now write a program to test if your
    >> printer is providing an incorrect length value, not including
    >> a semicolon, etc.

    >This is an incompatible change and so can't go in. :-(

    >However, if we lose the two length bytes and do the rest it should be

            What makes the two length bytes "incompatible"? Which programs
    does it break? The USB ioctl returns the length bytes, so my version
    keeps the format consistent, making it a bit easier to write tools
    that use the IEEE 1284.3 facility. Can you explain why we need a third

    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 Jan 16 2001 - 17:32:45 EST