> > register_pio_hook_ptr_r(PIO_IDE, SIZE_BYTE,&s->cmd[0]);
> > for (i = 1; i< 7; i++) {
> > register_pio_hook_ptr_r(PIO_IDE + i, SIZE_BYTE,&s->cmd[i]);
> > register_pio_hook_ptr_w(PIO_IDE + i, SIZE_BYTE,&s->cmd[i]);
> > }
>
> You can't easily serialize updates to that address with the kernel since two
> threads are likely going to be accessing it at the same time. That either
> means
> an expensive sync operation or a reliance on atomic instructions.
Who cares
If your API is right this isn't a problem (and for IDE the guess that it
won't happen you will win 99.999% of the time).
In fact IDE you can do even better in many cases because you'll get a
single rep outsw you can trap and shortcut.
> But not all architectures offer non-word sized atomic instructions so it gets
> fairly nasty in practice.
Thats their problem. We don't screwup the fast paths because some
hardware vendor screwed up that bit of their implementation. That's
*their* problem not everyone elses.
So on x86 IDE should be about 10 outb traps that can be predicted, a rep
outsw which can be shortcut and a completion set of inb/inw ops that can
be predicted.
You should hit userspace about once per IDE operation. Fix the hot paths
with good design and the noise doesn't matter.
Alan
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
