> > The reset-to-default behavior depends on the hardware's capability. Some
> > scanners support reset operation. Upon device close/open, a reset
> > command will be sent to the device. For those that don't support
> > hardware reset, the backend will call its own init_options() or similar
> > function to set default parameters for a device upon sane_init(),
> > sane_open() or sane_start()[1], then write such parameters to device to
> > acquire data. Some backend may even use all the methods to set initial
> > state of a scanner. Application can change the parameter values by
> > calling sane_control_option(). So, whenever a user starts to acquire
> > image data from a scanner, the scanner's state is reset.
>
> My understanding of the above summary is that "device clean" is
> effectively built into the API and to the scanimage(1) command.
> However given that the devices are managed by logindevperm when not
> running with Trusted Extensions this is more than should be necessary.
>
> When Trusted Extensions is enabled (svcadm enable labeled) the
> logindevperm entries that give access to the USB scanner devices (via
> libusb/ugen(7D)) are disabled from logindevperm. This means the system
> is "safe" though scanner devices can't be allocated.
>
> Fixing the allocation of non mass-storage/audio devices when running
> with Trusted Extensions is very much out of scope for this case. I
> think such a case is needed; but I don't currently see any value in
> derailing this case to write an opinion to say so. Instead I've logged
> bugster CR# 6676059.
As sort of a last word I hope %^}. Object reuse is a Solaris
requirement. Object reuse applies to ALL objects within Solaris.
(Trusted Extensions has labeling requirements for the import and
export of labeled data, the device allocation framework is used
to aid in meeting the labeling requirements)
The issue, as I see it, is that in this case's materials I noted
that there was a potential object reuse issue that didn't seem
to be dealt with. The issue deals with both data (documents
left in the scanner) and state. While this might be a general
USB libusb/ugen() issue, I'd not noticed it before. When I
was first looking at this it was for HAL. Devices managed
by HAL are configurable to do object reuse (through device
allocation). What's the resolution? This project team says
"not my job man". Management has given me the impression that
the team that integrates is responsible for the fullness of the
requirements. Do we unwind libusb/ugen() and have that team
(I'm guessing usb/usb_sw/ugen Frits Vanderlinden) complete the work?
Do we make this case dependent on that work being done by another
project? Or do we say, too bad, that's not going to get done and
this case makes it no worse? I don't believe writing an opinion
will provide value for this case. As this is doing no more
harm than the other things that might currently be present in
the non-mass-storage USB world, I'm not going to hold it up.
Fixing the missing general USB issues is a problem to be
raised to management.
Gary..
