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
...
-
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?
-
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
-
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
-
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