iopl() vs. ioperm() - Unix

This is a discussion on iopl() vs. ioperm() - Unix ; Newbie to iopl(), some work with ioperm() I'm writing a Linux function to do the following: 1. Gain access to the parallel port base at 0x378 2. Disable interrupts 3. Do some bit work, send signals, etc. 4. Enable interrupts ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: iopl() vs. ioperm()

  1. iopl() vs. ioperm()

    Newbie to iopl(), some work with ioperm()

    I'm writing a Linux function to do the following:

    1. Gain access to the parallel port base at 0x378
    2. Disable interrupts
    3. Do some bit work, send signals, etc.
    4. Enable interrupts
    5. Exit

    Currently I'm using ioperm() for gaining access to the port, but
    perhaps it's better to use iopl() and then a call to .asm cli and sti
    to disable and enable interrupts respectively. Thoughts?


  2. Re: iopl() vs. ioperm()

    philbo30 writes:

    > Newbie to iopl(), some work with ioperm()
    >
    > I'm writing a Linux function to do the following:
    >
    > 1. Gain access to the parallel port base at 0x378
    > 2. Disable interrupts
    > 3. Do some bit work, send signals, etc.
    > 4. Enable interrupts
    > 5. Exit
    >
    > Currently I'm using ioperm() for gaining access to the port, but
    > perhaps it's better to use iopl() and then a call to .asm cli and sti
    > to disable and enable interrupts respectively. Thoughts?


    Yes, I think you're way out of your league there. Until you learn why
    disabling interrupts from userspace will immediately lock up your
    system, you should stay away from directly accessing hardware.

    Whatever it is you want to do with the parallel port, it is probably
    possible to accomplish using operations on a standard device node.
    Using proper kernel interfaces to access hardware will let your
    program work even the parallel port is not available at the usual
    address, as would be the case on a non-PC platform or with a
    USB-parallel converter.

    The iopl() and ioperm() functions should be used rarely if ever. A
    slight mistake, or running on unexpected hardware, can easily crash
    the entire system.

    --
    Måns Rullgård
    mans@mansr.com

  3. Re: iopl() vs. ioperm()

    philbo30 wrote:
    > Newbie to iopl(), some work with ioperm()
    >
    > I'm writing a Linux function to do the following:
    >
    > 1. Gain access to the parallel port base at 0x378
    > 2. Disable interrupts
    > 3. Do some bit work, send signals, etc.
    > 4. Enable interrupts
    > 5. Exit
    >
    > Currently I'm using ioperm() for gaining access to the port, but
    > perhaps it's better to use iopl() and then a call to .asm cli and sti
    > to disable and enable interrupts respectively. Thoughts?


    Yes. Start using the proper ways to do this (read : using the right
    device). You can't disable interrupts from userspace, the're privileged
    operations restricted to kernelspace.



    Igmar

  4. Re: iopl() vs. ioperm()

    Igmar Palsenberg writes:
    >philbo30 wrote:
    >> Newbie to iopl(), some work with ioperm()
    >>
    >> I'm writing a Linux function to do the following:
    >>
    >> 1. Gain access to the parallel port base at 0x378
    >> 2. Disable interrupts
    >> 3. Do some bit work, send signals, etc.
    >> 4. Enable interrupts
    >> 5. Exit
    >>
    >> Currently I'm using ioperm() for gaining access to the port, but
    >> perhaps it's better to use iopl() and then a call to .asm cli and sti
    >> to disable and enable interrupts respectively. Thoughts?

    >
    >Yes. Start using the proper ways to do this (read : using the right
    >device). You can't disable interrupts from userspace, the're privileged
    >operations restricted to kernelspace.
    >


    Actually, the 'cli' and 'sti' instructions are conditioned on the IOPL
    (I/O Privilege level). This allows a program which is allowed to call
    iopl() (which is a privileged system call) to enable and disable interrupts.

    That said, it's a rather bad thing for an application writer on
    a general purpose system to do, espcially on a multiple processor system.

    scott

+ Reply to Thread