On Wed, Jul 19, 2000 at 12:56:24PM +0200, Uwe Bonnes wrote:
> Will it be standard with 2.4?
It's integrated into the 2.4 tree, yes.
> And any informations about the BSD interface?
Talk to Nicolas Souchu <nsouch@freebsd.org>.
> I use plain 2.2.16 with the VmWare modules.
Ah: don't use that. ;-)
I'm not maintaining ppuser; ppdev has a slightly different interface
(hence the name change), meaning that two different minors are two
different _ports_, not two different _devices_.
If you want to remain compatible with the ppuser stuff that VMware
ship, the best thing would be to actually _change_ ppuser to use this
interface too.
> But blocking inside the IOCTL is a bad idea i.m.h.o. I thinK the IOCTL
> should return EBUSY or such in that case and not wait inside the kernel.
We could add a non-blocking version next time round if you think it
would help (but I don't think it really will for your case).
> Well, that is the way I have to do in in Wine to, more or less. The
> user allows access to some devices and yet unknown user processes at
> yet unknown times access yet unknown IO Ports...
But are you trapping them? You could just configure WINE to pretend
that the port is at 0x378, and then redirect everything to
/dev/parport0.
> The idea of enclosing each PP[R|W]xxxx IOCTL isn't a good one either,
> as then some other process might do some action on that IOPORT
> meanwhile and things will go astray.
See PPEXCL.
> I think however that Wine should run timers for each claimed port and
> release the port after configured time of inactivity. On the next
> access it should rePPCLAIM again.
Or just claim the port for exclusive use.
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 2b29 : Wed Jul 19 2000 - 07:27:19 EDT