>> 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.=20
>Red Hat Linux's kudzu does, for one, although it doesn't really act on
>it very much yet.
>Presumably Lothar also does a similar kind of thing.
>Basically any kind of automatic printer detection/setup utility.
>It's not like this can't be done in user space anyway, in case the
>length field is absolutely needed.
We are changing the format of
/proc/sys/dev/parport/parport0/autoprobe either way, so these
programs would have to be changed either way. 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).
>> 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.
>All the other changes are good, and don't affect compatibility
>(noticeably). It's just the length field thing. I just think it's
>too late. MHO.
Again, I don't see the difference in compatability. Can you
replace terms like "compatability" and "I just think it's too
late" with specific technical facts.
>Just so that existing utilities know what 'autoprobe' is actually
>supposed to contain.
>At the moment, it contains something that can be parsed as an IEEE
>1284 Device ID, without a length field (with the length implicit in
>the number of bytes you can read from the file).
>With your change to make it re-read the device ID on demand, it still
>contains something that can be parsed as an IEEE 1284 Device ID, so
>there's no real format change. As soon as you put the length field in
>though the format changes.
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.
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. (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).
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 - 18:44:43 EST