Matto> With regards to the new, smarter configuration code:
Matto> a) It would be a good idea if the "attach" function which is
Matto> passed to sane_config_attach_matching_devices() took an extra
Matto> (void *) argument, to handle any additional data which it may
Matto> need/return.
I hope it won't be necessary. Rentrancy is not an issue since this is
used during initialization only so it would be perfectly ok to use
some static variables in the backend (the mustek backend does this,
for example).
Matto> b) sane_config_attach_matching_devices() should return
Matto> something, at least maybe the results of the called attach
Matto> function. One might want to know if it succeeds or not.
No. It is/was a common mistake for backends to complain and stop if
an attach during initialization fails. That's wrong (the attach
during initialization should be considered a "probe") and with the
current interface a backend writer simply can't make this mistake
anymore (or so I hope).
Matto> c) Might it not be cleaner if the attach_matching_devices
Matto> code would simply return a list of appropriate device name
Matto> strings, then the backend could go through and do what it
Matto> wants to each entry? (This would eliminate (a), (b), and
Matto> (f).)
A matter of taste, I'd say.
Matto> d) (Now, speaking from the perspective of the
Matto> mentally-challenged Microtek firmware: ) Aside from the
Matto> Microtek backend needing to look for at least five different
Matto> vendor strings (something new every day), one of these
Matto> strings is " " [8 spaces, returned by my very own E6]. The
Matto> sanei_config2.c code correctly handles quoted strings,
Matto> however the code which scans /proc/scsi (which has no quotes)
Matto> discards all this 'whitespace'.
That sounds ugly. I think we can fix it through (e).
Matto> e) How about adding the "Type:" from /proc/scsi/scsi as well?
Matto> "Scanner" is a good catch-all (except for the HP scanners),
Matto> and since the average user has only one scanner, this doesn't
Matto> hammer other devices.
Matto> (as it stands, only "scsi * * * * *" works for the E6,
Matto> which just assaults the entire scsi bus....)
Yes, I thought of that too. I'll add it.
Matto> f) A logic glitch: If a user does happen to have multiple
Matto> scanners of the same type in his system, the config code will
Matto> only attach the first one (after which, the function
Matto> returns).
I don't think so. It returns only if (*attach)() returns something
other than SANE_STATUS_GOOD, which happens only when a fatal error
occurs in the backend (such as when the mustek backend runs out of
memory, for example). At least, that's the idea...
I integrated your fix for the microtek backend. Thanks for the
feedback!
Cheers,
--david
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com