John Plocher wrote:
> 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
I think people are making this far more complex than it needs to be.
Don't worry about paper left in the scanner or similar types of human
error. The issue here is that the device needs to be effectively reset
when a new user starts to use it (or at least, it needs to avoid
returning data leftover from the previous user).
An analogous example is /dev/audio, which has some programmable
registers that retain state (e.g, for volume control). You want to make
sure that one user doesn't open the device and set the registers to some
state, thereby communicating information to the next user who opens the
device.
As I said, I would hope that the driver can guarantee the right behavior
so that device allocation is not needed.
Scott
