Tim Waugh <twaugh@redhat.com> 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
>wonder?
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
>okay.
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
format?
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 : Tue Jan 16 2001 - 17:32:45 EST