Am Donnerstag, 15. März 2012, 16:13:08 schrieb Alan Stern: > On Thu, 15 Mar 2012, Oliver Neukum wrote: > > But the command crashing the reader could come from user space, > > couldn't it? So I am afraid this is no solution. > > It is _a_ solution (it allows Wolfgang to print again), just not a > _perfect_ solution. Well, yes, but this solution allows users of the storage device to mess up the printing. > > It seems to me that we > > need to make the SCSI layer avoid a reset of this device. Then at least > > the printer would work reliably. > > But what happens if somebody does put in a memory card and the card > reader needs to be reset? Data could get lost. But the storage component is buggy. It seems to me that if we have a device with multiple component and only some of them are buggy, then the damage should occur to users of the buggy components. > A more secure approach would be to prevent usb-storage from binding to > the card reader at all. But this would have the disadvantage that > people wouldn't be able to use the card reader even while they weren't > printing. Exactly. > I can't think of any perfect solutions. Adding pre_reset and > post_reset support to usblp would be a good step, but I don't know > whether it would solve the problem. Probably not. It would make matters worse. The meaning of the stream of bytes transmitted to a printer depends on earlier parts of the stream. If a reset happens while something is printed, the partial page has to be discarded and the job restarted. Neither should we wait for printing to stop, as we could potentially wait forever. We'd need a way to refuse a reset. But I don't think that this is worth doing so. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
