You are not listening. Or I am not hearing.
What do you mean by "information remaining in the device"?
Please be explicit.
Even after deallocating and reallocating then,
o An audio input device still passes on sounds made in its
vicinity,
o A web camera still shows the images of whatever it is pointed
at, and
o A scanner still returns images of whatever is placed on its
scanning table or run thru its document feeder.
I'm pretty sure that we don't require that the audio or web camera
interfaces contain code that compares the current audio or video
stream with all previously processed streams to preclude the
transmission of similar or identical sounds or images - all we
require is that copies of those previously captured sounds or
images themselves are not exposed.
In a scanner, this would mean that the driver needs to
dispose of all cached and buffered content, state and what have
you when the device is returned to the system, but it would
not require a robot arm to open up the scanner lid and remove
forgotten documents from the scanning table, shred and burn them
when the device is deallocated.
Or, would it?
-John
Gary Winiger wrote:
>>> The same as we do /dev/audio. We reset any state that can be
>>
>> OK, maybe I'm dense, but what is the perceived failure mode here?
>> Is it "someone left a page on the scanner" or is it something else?
>
> It's that there is information remaining in the device that
> can be accessed after the device has been returned to the
> system and given to anothe person.
>
>> If it is the "can't flush page table :-)" problem, what is it
>> that you would expect to be done here? Not allow logout to happen
>> until scan() == empty_scan_platen() or some such? or ...?
>
> See allocate(1), deallocate(1), device_allocate(4), device_maps(4),
> and I thought there was a device_clean man page that I can't find.
>
> I expect the project team to supply whatever is necessary to
> work within the device allocation framework so the device
> is properly integrated therein. This may include stuff in
> devfsadm(1m), mkdevalloc(1m), mkdevmaps(1m), providing
> a clean script/program and so on.
>
> This stuff has all been part of SunOS since 5.3. Until recently,
> there's been very little activity in adding system components
> that needed special object reuse handling.
>
> Gary..
