InterruptLock - free for all?

Hi,

Firstly let me say I like QNX. However, I feel a little uneasy about
something - maybe someone can eliviate my fears. I guess one of the great
bonuses of a micro-kernel OS is determinism of interrupt latency through the
kernel. However, what stops any user level process, including a badly
written app, from calling InterruptLock on the schedulers interrupt and
locking everything out - and in effect locking the processor.

Thanks

DAN

I believe that the InterruptLock function can not be called
until you have made a ThreadCtl( _NTO_TCTL_IO, 0 ) call,
which you have to be root to do. And if you are root
and have called that you have said “Let me do as I please
even if it may be stupid, I know what I am doing, really…”

-Peter

Daniel G Waddington <dwaddington@lucent.com> wrote:

Hi,

Firstly let me say I like QNX. However, I feel a little uneasy about
something - maybe someone can eliviate my fears. I guess one of the great
bonuses of a micro-kernel OS is determinism of interrupt latency through the
kernel. However, what stops any user level process, including a badly
written app, from calling InterruptLock on the schedulers interrupt and
locking everything out - and in effect locking the processor.

Thanks

DAN

O.k., so from the docs I see ThreadCtl controls permission to attach IRQ
handlers also, so does this infer that device drivers must be run as root
(atleast if they want to attach to an interrupt)?


DAN

<pgraves@qnx.com> wrote in message news:90opbf$g55$1@nntp.qnx.com

I believe that the InterruptLock function can not be called
until you have made a ThreadCtl( _NTO_TCTL_IO, 0 ) call,
which you have to be root to do. And if you are root
and have called that you have said “Let me do as I please
even if it may be stupid, I know what I am doing, really…”

-Peter

Daniel G Waddington <> dwaddington@lucent.com> > wrote:
Hi,

Firstly let me say I like QNX. However, I feel a little uneasy about
something - maybe someone can eliviate my fears. I guess one of the
great
bonuses of a micro-kernel OS is determinism of interrupt latency through
the
kernel. However, what stops any user level process, including a badly
written app, from calling InterruptLock on the schedulers interrupt and
locking everything out - and in effect locking the processor.

Thanks

DAN

Daniel G Waddington <dwaddington@lucent.com> wrote:

O.k., so from the docs I see ThreadCtl controls permission to attach IRQ
handlers also, so does this infer that device drivers must be run as root
(atleast if they want to attach to an interrupt)?

To have access to the hardware – io operations, memory mapping
physical addresses, attaching interrupt handlers, masking interrupts,
disabling interrupts all require root (superuser) permission.

If you can write a device driver without these, then you can write a
device driver that doesn’t need to run as root.

(For some definitions of device driver this could actually make
sense… if something else interfaces with the hardware, eg a
printer “driver” that knows how to write the appropriate graphics
language for the printer (postscript, hpgl, etc) but just spits the
bytes out using open(/dev/par), write() or a GPS receiver that talks
to a GPS sitting on a serial port with open(/dev/ser1), read() would
be possibly examples of something in this class.)

But, generally, device drivers since they deal with hardware devices
require root to run.

-David