On Wed, Jan 17, 2001 at 01:58:32AM -0800, Adam J. Richter wrote:
> I expect the updated versions of existing programs to skip
> the first two bytes, especially since, according the kernel code,
> that count is not always reliable anyhow. That's not a big change,
> and should not provoke any new null termination problems.
> You have the logic backwards. The current format is a
> well defined subset of valid IEEE 1284 strings.
It was always supposed to be parseable as a device ID, but without the
(implicit) length field. But yes, perhaps people have read the code
and are making assumptions.
> So, current parsers
> of that format probably are not written to handle all possible
> IEEE 1284 strings. Switching to passing the actual ID string,
> whether we include the length bytes or not, will require these
> parses to handle possibilities that they did not previous need to
Okay. Then we need to at least change the name. Call them deviceid
2.4.0 is out already, and as much as possible I want the interfaces to
remain stable throughout 2.4.x.
It doesn't matter if we just rename autoprobe* to deviceid* though,
along with that semantic change of including the length field, since
parsers need to be able to deal with kernels without support for them
But we can't just change the format of a file that's been there since
2.2, _after_ 2.4.0 has been released.
> The only programs that you so far have suggested may be effected are
> distribution specific.
I can't say with any certainty, and neither can you, that there aren't
> If this is acceptable to you, I can make a new patch against
> 2.4.1-pre8 if that would help.
Change the names to 'deviceid' instead of 'autoprobe', and change the
sysctl numbers too, and I'll be a _lot_ happier.
We really need a library to deal with this kind of stuff. Something
Fallback to /proc/sys/dev/parport/*/autoprobe*
Fallback to /proc/parport/*/autoprobe
Fallback to /dev/parport* (there are more dragons here actually:
VMware's vmppuser has some differences to ppdev)
Fallback to iopl.
I'll write it if no-one beats me to it.
-- To unsubscribe, send mail to: email@example.com --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Wed Jan 17 2001 - 08:01:56 EST