Grant Grundler wrote:
After three years of using/maintaining the (trivial) tulip patch
in parisc-linux tree (and shipped with RH/SuSe ia64 releases),
I don't recall anyone complaining that udelays in tulip phy reset
caused them problems. Sorry, I'm unmotivated to revisit this.
Convince someone else to make tulip to use workqueues and I'll
resubmit a clean patch on top of that for the phy init sequences.
Long delays are unacceptable in new drivers, and we are working to
remove them from older drivers. Lack of complaints is irrelevant -- its
a design requirement of all drivers.
Ingo and the real-time crowd are fighting against every delay, because
every delay causes a spin, a blip in latency, an increase in CPU usage,
and a complete stoppage of ALL work on a uniprocessor machine.
Your patch is not a special case. We have been communicating this
message on udelay/mdelay for -years-. All your patch [as-is] does is
cause more work for someone else.
This also presents a problem that Andrew points out on occasion:
what happens when a patch is useful, but the patch author isn't (for
whatever reason) doing the legwork necessary to get it into the mainline
kernel? We certainly DON'T want to lose this patch, as the changes are
useful.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
