* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

quoted text
> > udelay is supposed to be reliable. If someone runs a new kernel and 
> > has no TSC (which might happen even on modern hardware or with 
> > notsc) _and_ finds that udelay is not calibrated well enough then 
> > that's a kernel bug we want to fix.
> 
> You miss the point entirely. The delay is in bus clocks not CPU 
> clocks, not tsc clocks not PIT clocks, and it is permitted to vary by 
> a factor of two. So you'll worst case halve the speed of network 
> packet up/download even if your udelay is accurate.

ok, you are right. How about we go with one of your suggestions: rename 
the API family to isa_*_p() in the affected ISA drivers? That makes it 
perfectly clear that this is an ISA related historic quirk that we just 
cannot properly emulate in an acceptable fashion. It will also make the 
least amount of changes to these truly historic drivers.

The main maintenance thing we are interested in is to have no subsequent 
new uses of this API and to eliminate these accesses from modern 
hardware - and naming it clearly 'ISA' and making it dependent on 
CONFIG_ISA would likely achieve that purpose.

oh, another thing: there are 100+ mails in this thread while there are 
only 3 mails in the thread that lists 61 not-yet-fixed-in-2.6.24 
regressions:

|  Listed regressions statistics:
|
|  Date          Total  Pending  Unresolved
|  ----------------------------------------
|  Today           139       38          23

which is a sad proportion of attention :-/

	Ingo
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/