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

From: Tim Waugh (
Date: Wed Jan 17 2001 - 04:04:24 EST

  • Next message: Adam J. Richter: "Re: [PARPORT] PATCH: parport_device_id support, "version 2.0""

    On Tue, Jan 16, 2001 at 03:42:39PM -0800, Adam J. Richter wrote:

    > We are changing the format of
    > /proc/sys/dev/parport/parport0/autoprobe either way,

    Not so.

    > so these
    > programs would have to be changed either way.

    Not so.

    > The differences are that by including the length bytes, we are
    > compatible with the USB practice and it is easier to write user
    > level utilities to do things like identify which printers have
    > incorrect length values (e.g., to catalog that information over the
    > net).

    I agree that it would be desireable to include the length bytes.

    > Again, I don't see the difference in compatability.


    In the vast majority of cases, one of the two bytes will be zero. You
    don't see a problem with that, for programs that are expecting an
    ASCII string?

    > The current format of autoprobe contains line feeds and only
    > long field names. I would think that any program that currently
    > uses it will have to be updated either way, although there are few
    > programs at this point.

    Not so again. The current format is 'just like' a length-fieldless
    IEEE 1284 Device ID, in that it can be parsed in exactly the same
    way. The line feeds don't matter because parsers need to ignore white
    space (IEEE 1284 even says this).

    Changing it to return the real device ID (but without the length
    field) will _still_ return a string that can be parsed 'just like' a
    length-fieldless IEEE 1284 Device ID. Changing it to also return the
    length field obviously changes this.

    > There are a couple of programs that I am considering writing
    > (but, of course, hoping that someone else will save the trouble) that
    > need the IEEE-1284.3 data. Either format could work with such a program
    > but I would like get as close to doing the IEEE-1284.3 parsing "the right
    > way" so that they do not have to be changed as often.

    If you think that having the length field in is more important than
    keeping compatibility, you need to seek out the authors of any
    programs that will be affected.

    > (The programs that I want are a simple facility for sending the IEEE
    > 1284 data to a public network database so distribution maintainers
    > could notice new device ID's as they appear and a variant of this
    > that would generate printcap entries on the fly).

    Good idea. :-)


    -- To unsubscribe, send mail to: --
    -- with the single word "unsubscribe" in the body of the message. --

    This archive was generated by hypermail 2b29 : Wed Jan 17 2001 - 04:06:49 EST