Misinterpretation of Standard Causing USB Disconnects On Resume In Linux
hypnosec writes "According to a new revelation by Sarah Sharp, misinterpretation of the USB 2.0 standard may have been the culprit behind USB disconnects on resume in Linux all along rather than cheap and buggy devices. According to Sharp the USB core is to blame for the disconnections rather than the devices themselves as the core doesn't wait long enough for the devices to transition from a 'resume state to U0.' The USB 2.0 standard states that system software that handles USB must provide for 10ms resume recovery time (TRSMRCY) during which it shouldn't attempt a connection to the device connected to that particular bus segment."
It's true. Linus has been quite vocal about whose fault it is when a kernel change breaks an application...
"Because Science" is one step from "Because old book". Try "Because of my experiment testing my falsifiable assertion".
For all practical purposes there's no way, I repeat, no way to "heat the whole apartment block" to eradicate bed bugs.
So you don't know what you are talking about.
If anyone can enlighten me as to why thats wrong, Id appreciate it.
1. syscall returns -EFOO when to report condition A
2. hmm, someone notices that -EFOO is too generic. That syscall should return the more specific -ECOND_A_ERROR instead. They change it.
3. ALL SOFTWARE suddenly works *different* and perhaps does not work at all on the modified kernel that uses that syscall vs.older kernel.
Kapish??
Do not change API internals. Fixing undocumented features (ie. bugs, like overflows) is one thing. Modifying documented and established API on a whim is a bad bad bad thing.
If you want to modify it like that, you do the following,
1. syscall returns -EFOO when to report condition A
2. hmm, someone notices that -EFOO is too generic. That syscall should return the more specific -ECOND_A_ERROR instead. SO MAKE A NEW SYSCALL THAT RETURNS CORRECT! Leave old one as deprecated for removal in some years.
3. ALL SOFTWARE continues to work.
If #2 is too much effort for reward, then do nothing. But above all, do not break userland with kernel changes. Ever.