Tim Waugh writes:
> > The first problems is with the (not yet exiting) standard for the
> > ppuser/ppdev header which makes it hard for the compile time detection
> > of ppuser/ppdev capabilities. Wine is configured via './configure' and
> > ideas for a portable detection of ppuser/ppdev capabilities via
> > autoconf are welcome. Is ppuser/ppdev available on other system
> > then linux?
> It isn't available anywhere but Linux. *BSD has a similar device I
> think, but it has an entirely different interface. ( :-( )
Will it be standard with 2.4?
And any informations about the BSD interface?
> > The second problem is a real showstopper. This is with run time
> > detection of the capabilities of the parport devices given by the user
> > in the wine configuration. As it is not know when the user process
> > will access what port, I must open and PPCLAIM all user configured
> > ports. I must expect this user configuration to be broken. This might
> > result in a sequence like
> > fd1=open("/dev/parport00",O_RDWR);
> > ioctl(fd1,PPCLAIM,0);
> > fd2=open("/dev/parport01",O_RDWR);
> > ioctl(fd2,PPCLAIM,0);
> > In this situation the second ioctl hangs _uninterruptible_ as the
> > secon PPCLAIM will wait for a PPVIELD on the first device...
> Do /dev/parport00 and /dev/parport01 definitely have different minors?
> Which kernel version are you using? This sounds like a bug: two ports
> are entirely separate from one another and so claims on them should
> not interfere with each other.
Some information I forget to give in the first mail.
I can reproduce the error by commenting out the close() and PPYIELD
lines in ppdemo from ppuser. If you try yourselt, copy the ppdemo to a
small filesystem before starting. Because if you trigger that error
too, you can't get the parallel port back until you reboot and the
filesystem containing the ppdemo executable will be shut down unclean.
I use plain 2.2.16 with the VmWare modules.
The devices have different minor. But as said above, both devices use
the same parallel hardware.
But as I am checking user input in that moment, it might even be
possible that the user has a misconfigured system with different
devicenames with the same minor. And the system should survive that
situation too and report the problem.
PPCLAIM translates into parport_claim_or_block. In my understanding
the idea of PPCLAIM is to share two external devices
on the same hardware parallel port. So while one process was
transfering data to one external device, another process trying to
transfer to a second device should be denied that transfer as long as
the first process didn't PPYIELD the parallel port hardware.
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.
> PPGETBASE was added to ppuser for VMware because they wanted a
> short-term solution, and only used /dev/parport devices in order to
> claim the port; from then on they just go straight to the hardware.
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...
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.
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.
Uwe Bonnes email@example.com
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
-- To unsubscribe, send mail to: firstname.lastname@example.org --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Wed Jul 19 2000 - 06:59:29 EDT