OK, here is a patch that restores the "compatability" routines
that I believe are never used. I wanted to have all of the unneeded
code in a separate file which would build a separate module in the
modularized case, but exporting the "topology" variable, with its
own structure format, from daisy.c was just too ugly. So, a small
helper routine, parport_find, is in daisy.c.
After this, what I would like to do is extend struct
parport_driver (in a compatible way) to take an optional
ID table, so the routine that calls parport_driver->attach
can filter out devices that do not match, if desired. What is
unclear to me right now is how daisy chaining can fit into this.
Is it generally true that devices that have IEEE-1284.3 device ID's
are also accessible through this daisy chaining mechanism? If so,
then it would probably make sense to add a paramaeter to
parport_driver->attach to indicate which device on the chain to
attach to. Since old drives could just ignore the parameter, it
would be compatible. If other devices on the daisy chain are generally
not accessible, then only then only parport.probe_strings[0]
should be considered.
-- 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 : Sun Jan 21 2001 - 08:02:14 EST