Re: [PARPORT] user-space drivers


Tim Waugh (tim@cyberelk.demon.co.uk)
Fri, 4 Jun 1999 20:00:35 +0100 (GMT)


Hi Uwe,

On Fri, 4 Jun 1999, Uwe Bonnes wrote:

> thinking of doesmu/wine, could ppuser also grant access to the
> extended port registers?

They might not exist. read/write are there for doing the special IEEE
1284 modes, and if the hardware can help it probably will. If the
extended registers don't exist, read/write will do the protocol in
software.

There are situations where this isn't fast enough: for those situations,
an in-kernel driver is probably a better solution, or else (as in VMware's
case at the moment) doing the inb/outb by hand might be more suited to the
situation.

DOSEmu and WINE aren't quite in the same boat as VMware, from what I can
tell. When VMware has trapped the I/O instruction, it's in some 'weird
secret mode' which takes some getting out of to get back to user space at
all, and that might well be where the bottle-neck comes from.

On the other hand, all three are trying to do the same kind of thing in
slightly different ways, in that there are guest applications that are up
to things we can only guess at. The plan is to pretend that the existing
hardware can do lots and lots; that way we get to know more about what the
guest application is trying to do. If we get to virtually 'DMA' some
data, for instance, that's a large block read/write, and so the kernel
(parport) will do most of the work (and it may even end up being properly
DMA'd). The same kind of thing goes for FIFOs and 32-bit registers.

If the 'virtual' hardware presented to the guest application is capable of
the advanced things, performance will.. suck less. ;-)

Tim.
*/

-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --



This archive was generated by hypermail 2.0b3 on Fri 04 Jun 1999 - 15:31:11 EDT