Alan Cox wrote: >> If the hardware required an intermediate junk I/O, that would be a >> reason to do one, but it doesn't, does it? It requires a delay. It's >> written thus in all of the application notes. >> > > And the only instruction that is synchronized to the bus in question is > an I/O instruction. >
This is a timing issue, isn't it? How are we synchronising, other than by delaying for a (bus-dependant) period? The characteristics of each bus are known so a number can be assigned for "one bus cycle", without having to use the bus. >> Wrong again. Of course one knows how long the delay should be. The bus >> speed is known. >> > > Wrong again. ISA bus speed is neither defined precisely, nor visible in a > system portable fashion. > You say, "system portable," but I think you mean, "automatically determined." We don't have to define this value automatically, if that's so hard to do. We can use a tunable kernel-parameter. > I'm so glad you have nothing better to do than troll I'm not trolling. You know this is true because many people perceive this to be a problem. I'm working on fixing it. Not all Linux problems are solvable by diving into code, and there is anecdotal evidence to believe this one has big performance considerations. I don't understand why you are opposed to even talking about it. > if you > actually wrote code I'd be worried it might get into something people > used. Speaking of writing code: I remember working on a bluetooth Oops. Lacking the hardware, I went to you for advice on how to get it before someone for testing. You never replied. -- 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/