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...
If you cannot do that, it's infinite loop. You always have to consider
the worst case. To simply keep trying only _hoping_ that there'll be
resources some time is voodoo.
Besides storage, the foremost user, will time out, because the SCSI layer
does and under these conditions you have killed the storage driver.
Oh, go actually try the code before you say things like that. I don't
think you've actually looked at how the fault paths work ... yesterday
you assumed it didn't try to report the actual_length, and today you're
assuming that it doesn't even implement cancelation vaguely correctly.
UTSL; develop and run tests.
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.
So I completely fail to see what you're saying is _not_ done.
- Dave
-------------------------------------------------------
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
