Am Donnerstag, 23. Januar 2003 17:59 schrieb David Brownell:
> Oliver Neukum wrote:
> > Am Donnerstag, 23. Januar 2003 07:12 schrieb David Brownell:
> >>Oliver Neukum wrote:
> >>>Like this version better?
> >>
> >>No, it still has that "arbitrary timeout" pessimization. The only
> >>difference is a bigger timeout.
> >>
> >>
> >> An infinite loop is never
> >>
> >>>acceptable.
> >>
> >>That's because they don't make efficient use of BogoMIPS; the time is
> >>better spent cracking ciphers. But this isn't such a loop.
> >
> > Then go hence and show how you can be _sure_ that it'll exit.
>
> Sorry, I have Real Work to do instead. I'd far rather see you
> prove that the whole kernel doesn't deadlock well before any
> load gets heavy enough to even raise this issue with USB...
SO STOP COMPLAINING !
At least I fix the bugs I find.
> assuming that it doesn't even implement cancelation vaguely correctly.
> UTSL; develop and run tests.
It doesn't. You can cancel only what you have submitted. Which the
loop may have done, or may not have done. This is code running
in kernel mode it sleeps only with TASK_UNINTERRUPTIBLE.
It must be running in some context to run at all. As it runs in the context
of the kernel thread in storage if used by the storage driver, that
kernel thread will run only that code until the loop terminates. Hence
the driver has just died. Not that hard to understand, is it?
> The right way to handle _policy_ decisions like "should I abort this
> request" is to push them up to layers that are equipped to make such
> decisions. The current calls do exactly that; and you're saying that
> usb-storage (through the SCSI code) already has such policies.
To do so the code must return. You cannot assume that memory is available.
Oliver
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
