Re: [PARPORT] PPUSR/PPDEV for Wine and possible uninterruptible hang

From: Uwe Bonnes (
Date: Wed Jul 19 2000 - 06:56:24 EDT

  • Next message: Tim Waugh: "Re: [PARPORT] PPUSR/PPDEV for Wine and possible uninterruptible hang"

    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

    Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
    --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

    -- To unsubscribe, send mail to: --
    -- 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