Is it useful to support user level drivers

Is it useful to support user level drivers

[Balbir Singh]

I realize that the Linux kernel supports user
level drivers (via ioperm, etc). However interrupts
at user level are not supported, does anyone think
it would be a good idea to add user level interrupt
support ? I have a framework for it, but it still
needs
a lot of work.

Depending on the response I get, I can send out
more email. Please cc me to the replies as I am no
longer a part of the Linux kernel mailing list - due
to the humble size of my mail box.

Balbir

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Re: Is it useful to support user level drivers

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

On Thu, Jun 21, 2001 at 03:41:32AM -0700, Balbir Singh wrote:

> I realize that the Linux kernel supports user level drivers (via
> ioperm, etc). However interrupts at user level are not supported,
> does anyone think it would be a good idea to add user level
> interrupt support ? I have a framework for it, but it still needs a
> lot of work.

Well, for parallel port devices, take a look at libieee1284 and
/dev/parport0.

Tim.
*/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Is it useful to support user level drivers

[Alan Cox]

> level drivers (via ioperm, etc). However interrupts
> at user level are not supported, does anyone think
> it would be a good idea to add user level interrupt
> support ? I have a framework for it, but it still
> needs
> a lot of work.

The problem is that the IRQ has to be cleared in kernel space, because otherwise
you may deadlock. 

Re: Is it useful to support user level drivers

[Balbir Singh]

--- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> The problem is that the IRQ has to be cleared in
> kernel space, because otherwise
> you may deadlock. 
> 

I agree, the idea is to clear the IRQ in kernel space
and then deliver to user level programs interested
using a signal (Real time SIGINT or something similar)
If somebody is interested I could in sometime come
up with what I have in mind and send it to this list,
accept comments and criticism.

Balbir


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Re: Is it useful to support user level drivers

[Alan Cox]

> I agree, the idea is to clear the IRQ in kernel space
> and then deliver to user level programs interested
> using a signal (Real time SIGINT or something similar)
> If somebody is interested I could in sometime come
> up with what I have in mind and send it to this list,
> accept comments and criticism.

I think you should yes. The XFree86 people for one are trying to find a way
to handle vertical blank interrupts nicely

Re: Is it useful to support user level drivers

[Pavel Machek]

Hi!

> > The problem is that the IRQ has to be cleared in
> > kernel space, because otherwise
> > you may deadlock. 
> > 
> 
> I agree, the idea is to clear the IRQ in kernel space
> and then deliver to user level programs interested

...*IF* you know how to clear it. THat differs device-to-device.
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: Is it useful to support user level drivers

[Dmitry A. Fedorov]

On Thu, 21 Jun 2001, Alan Cox wrote:

> > it would be a good idea to add user level interrupt
> > support ? I have a framework for it, but it still
> 
> The problem is that the IRQ has to be cleared in kernel space, because otherwise
> you may deadlock. 

It depends on device type. Good designed ones does not raises a new
interrupt until an explicit acknowledge by I/O from [user space] driver
will be received.

Access to device's ports and IRQs from user space is subject
of system admistration policy so direct access to a dangerous devices
should not be allowed.

Lastly an IRQ kernel module can disable_irq() from interrupt handler
and enable it again only on explicit acknowledge from user.

Re: Is it useful to support user level drivers

[Oliver Neukum]

> > The problem is that the IRQ has to be cleared in kernel space, because
> > otherwise you may deadlock.
>
> It depends on device type. Good designed ones does not raises a new
> interrupt until an explicit acknowledge by I/O from [user space] driver
> will be received.
>
> Access to device's ports and IRQs from user space is subject
> of system admistration policy so direct access to a dangerous devices
> should not be allowed.
>
> Lastly an IRQ kernel module can disable_irq() from interrupt handler
> and enable it again only on explicit acknowledge from user.

Unless you need that interrupt to be enabled to deliver the signal or let 
userspace reenable the interrupt.

In addition, how do you handle shared interrupts ?

	Regards
		Oliver

Re: Is it useful to support user level drivers

[Dmitry A. Fedorov]

On Thu, 21 Jun 2001, Oliver Neukum wrote:

> > Lastly an IRQ kernel module can disable_irq() from interrupt handler
> > and enable it again only on explicit acknowledge from user.
> 
> Unless you need that interrupt to be enabled to deliver the signal or let 

Need not. Signal and other event delivery mechanisms has nothing
common with disable/enable_irq().

> userspace reenable the interrupt.

"user acknowledge" is mean that.


> In addition, how do you handle shared interrupts ?

It is impossible, see my another message.

Re: Is it useful to support user level drivers

[Oliver Neukum]

On Thursday, 21. June 2001 16:46, Dmitry A. Fedorov wrote:
> On Thu, 21 Jun 2001, Oliver Neukum wrote:
> > > Lastly an IRQ kernel module can disable_irq() from interrupt handler
> > > and enable it again only on explicit acknowledge from user.
> >
> > Unless you need that interrupt to be enabled to deliver the signal or let
>
> Need not. Signal and other event delivery mechanisms has nothing
> common with disable/enable_irq().

And how do you ensure that no interrupt is lost ?
In fact you now are likely to have a race condition reading device status or 
the like.

> > userspace reenable the interrupt.
>
> "user acknowledge" is mean that.
>
> > In addition, how do you handle shared interrupts ?
>
> It is impossible, see my another message.

Which IMHO makes the concept pretty much useless.
Interrupt sharing is pretty much the norm today. And there is no evidence for 
this to change in the near future. Rather the opposite seems to happen in 
fact.

Which devices were you thinking of, that need a hardware IRQ and no kernel 
driver ?

	Regards
		Oliver

Re: Is it useful to support user level drivers

[Dmitry A. Fedorov]

On Thu, 21 Jun 2001, Oliver Neukum wrote:

> > > In addition, how do you handle shared interrupts ?
> >
> > It is impossible, see my another message.
> 
> Which IMHO makes the concept pretty much useless.
> Interrupt sharing is pretty much the norm today. And there is no evidence for 
> this to change in the near future. Rather the opposite seems to happen in 
> fact.
> 
> Which devices were you thinking of, that need a hardware IRQ and no kernel 
> driver ?

An ISA cards, mostly for data acquisition - edge triggered interrupts,
no ack required immediately from interrupt handler. Rest of hardware
handling can be deferred to user space.
IRQ sharing is possible there in spite of some hardware hacking.

Yes, it is very limited range of hardware today but it exists
and /dev/irq kernel module provide one of generic mechanisms for user
space driver implementation.

Re: Is it useful to support user level drivers

[Balbir Singh]

Thanks folks, I got some great comments, pointers a
list of problems which I need to take care of.
I promise that when I try and implement user
level interrupts - it won't be a hack, all problems
will be taken  care of based on good programming
practices.

I will look into the steps provided by people.
Yes! we need to worry about shared interrupts, I will
draw out a more detailed plan of problems and
solutions.

Later ...

Thanks,
Balbir


--- "Dmitry A. Fedorov" <D.A.Fedorov@inp.nsk.su>
wrote:
> On Thu, 21 Jun 2001, Oliver Neukum wrote:
> 
> > > > In addition, how do you handle shared
> interrupts ?
> > >
> > > It is impossible, see my another message.
> > 
> > Which IMHO makes the concept pretty much useless.
> > Interrupt sharing is pretty much the norm today.
> And there is no evidence for 
> > this to change in the near future. Rather the
> opposite seems to happen in 
> > fact.
> > 
> > Which devices were you thinking of, that need a
> hardware IRQ and no kernel 
> > driver ?
> 
> An ISA cards, mostly for data acquisition - edge
> triggered interrupts,
> no ack required immediately from interrupt handler.
> Rest of hardware
> handling can be deferred to user space.
> IRQ sharing is possible there in spite of some
> hardware hacking.
> 
> Yes, it is very limited range of hardware today but
> it exists
> and /dev/irq kernel module provide one of generic
> mechanisms for user
> space driver implementation.
> 


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Re: Is it useful to support user level drivers

[Abramo Bagnara]

"Dmitry A. Fedorov" wrote:
> 
> On Thu, 21 Jun 2001, Oliver Neukum wrote:
> 
> > > Lastly an IRQ kernel module can disable_irq() from interrupt handler
> > > and enable it again only on explicit acknowledge from user.
> >
> > Unless you need that interrupt to be enabled to deliver the signal or let
> 
> Need not. Signal and other event delivery mechanisms has nothing
> common with disable/enable_irq().
> 
> > userspace reenable the interrupt.
> 
> "user acknowledge" is mean that.
> 
> > In addition, how do you handle shared interrupts ?
> 
> It is impossible, see my another message.

I don't see why you think it's impossible, the only thing you need is
that your kernel module know how to discriminate the interrupt source.

You can do this also with a irq.o module and other tiny modules that
register their irq source detection code.

Then you have /dev/irqX with the following API:

- ioctl(fd, IRQ_SUBSCRIBE, source_id);
- ioctl(fd, IRQ_ACK, source_id);
- poll
- async notification

Interrupts received between notification and acknowledge are queued
(i.e. counted). An alternative to queuing (user selectable) is to block
interrupt generation at hardware level in kernel space immediately
before notification.

I'm missing something?

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

Re: Is it useful to support user level drivers

[Alan Cox]

> (i.e. counted). An alternative to queuing (user selectable) is to block
> interrupt generation at hardware level in kernel space immediately
> before notification.
> 
> I'm missing something?

IRQ 9 shared between user space app and disk. IRQ arrives is disabled and
reported, app wakes up, app wants to page in code, IRQ is disabled, box dies

You have to handle that in kernel space, at least enough to handle the
irq event, ack it and queue the data

Re: Is it useful to support user level drivers

[Abramo Bagnara]

Alan Cox wrote:
> 
> > (i.e. counted). An alternative to queuing (user selectable) is to block
> > interrupt generation at hardware level in kernel space immediately
> > before notification.
> >
> > I'm missing something?
> 
> IRQ 9 shared between user space app and disk. IRQ arrives is disabled and
> reported, app wakes up, app wants to page in code, IRQ is disabled, box dies
> 
> You have to handle that in kernel space, at least enough to handle the
> irq event, ack it and queue the data

I try to be more clear:

Kernel space:
- irq 9 arrives from our device
- interrupts are disabled
- our kernel space micro handler is invoked
- interrupt source is checked
- if no notification is pending a signal is notificated for user space
(or a process is marked runnable)
- optionally our device interrupt generation is disabled
- handler returns
- interrupts are enabled

User space:
- signal arrive (or process is restarted)
- action is done
- notification is acknowledged (using an ioctl)

Kernel space:
- if we have other notifications to do, do one
- optionally our device interrupt generation is reenabled

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

Re: Is it useful to support user level drivers

[Richard B. Johnson]

On Thu, 21 Jun 2001, Abramo Bagnara wrote:

> Alan Cox wrote:
> > 
> > > (i.e. counted). An alternative to queuing (user selectable) is to block
> > > interrupt generation at hardware level in kernel space immediately
> > > before notification.
> > >
> > > I'm missing something?
> > 
> > IRQ 9 shared between user space app and disk. IRQ arrives is disabled and
> > reported, app wakes up, app wants to page in code, IRQ is disabled, box dies
> > 
> > You have to handle that in kernel space, at least enough to handle the
> > irq event, ack it and queue the data
> 
> I try to be more clear:
> 
> Kernel space:
> - irq 9 arrives from our device
> - interrupts are disabled
> - our kernel space micro handler is invoked
> - interrupt source is checked
> - if no notification is pending a signal is notificated for user space
> (or a process is marked runnable)
> - optionally our device interrupt generation is disabled
> - handler returns
> - interrupts are enabled

It just broke. The handler returned before the cause of the interrupt
was handled. Think LEVEL interrupts. The same interrupt will again
be entered, looping over and over again, until the tiny bit if CPU
resource available for the few instants the handler was not in the
ISR, was enough for the user-mode signal-handler to shut the
damn thing off, pull the plug, and figure this will never work.

> 
> User space:
> - signal arrive (or process is restarted)
> - action is done
> - notification is acknowledged (using an ioctl)
> 

Way too late see above.


> Kernel space:
> - if we have other notifications to do, do one
> - optionally our device interrupt generation is reenabled
> 
> -- 

Over and over again, I find more and more persons who haven't
a clue about what an interrupt is and how it relates to the
rest of the system. The start of this debacle occurred when
CPUs became fast enough so sloppy 'C'-coders were able to
make so-called interrupt handlers that kind of worked. Then
others, looking at the code, said; "Oh! This is just ordinary
'C' code. Good, I can do this stuff too....". Ultimately we
will have so-called Software Engineers reading and writing
files in interrupt service routines.

There is no such thing as a "user mode" interrupt service routine.
There never was one, and there will never be one on any machine
that fetches instructions from memory for execution. Remember
the Dr. Dobbs articles about "Interrupt THUNKS", you could
use in real-mode interrupt service routines? No need to answer.
They never worked, and they could never work. Remember "Call-backs"
from interrupt service routines? They never worked either. These
are all creations of coders, not Engineers, not even Technicians,
coders who learned how to use a tool (a compiler), who came up
with these "brilliant" ideas! Just because somebody published an
article, doesn't mean that anything written therein was correct.

FYI. The purpose of an interrupt service routine is to handle
the immediate needs of the hardware. That's all!  There is
nothing "immediate" in user-mode.

In a virtual memory system, the user's handler probably isn't
even in memory at the time an interrupt arrives. And, it can't
be paged into memory because the interrupt was for Disk I/O.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: Is it useful to support user level drivers

[Abramo Bagnara]

"Richard B. Johnson" wrote:
> 
> It just broke. The handler returned before the cause of the interrupt
> was handled. Think LEVEL interrupts. The same interrupt will again
> be entered, looping over and over again, until the tiny bit if CPU
> resource available for the few instants the handler was not in the
> ISR, was enough for the user-mode signal-handler to shut the
> damn thing off, pull the plug, and figure this will never work.

Sorry, I've missed an action writing the previous message (now marked
with a +)

Kernel space:
- irq 9 arrives from our device
- interrupts are disabled
- our kernel space micro handler is invoked
- interrupt source is checked
+ interrupt is acknowledged to our device
- if no notification is pending a signal is notificated for user space
(or a process is marked runnable)
- optionally our device interrupt generation is disabled
- handler returns
- interrupts are enabled

> >
> > User space:
> > - signal arrive (or process is restarted)
> > - action is done
> > - notification is acknowledged (using an ioctl)
> >
> 
> Way too late see above.

Don't equivocate me: this not the IRQ acknowledge, it's the acknowledge
of the user space notification.

Also note that this mechanism is not an attempt to demonstrate that to
move interrupt handlers to user space is a good thing. I wanted only to
show a way to permit to have *pseudo* interrupt handlers in user space
also having shared IRQ.

-- 
Abramo Bagnara                       mailto:abramo@alsa-project.org

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

ALSA project               http://www.alsa-project.org
It sounds good!

Re: Is it useful to support user level drivers

[Oliver Neukum]

> Kernel space:
> - irq 9 arrives from our device
> - interrupts are disabled
> - our kernel space micro handler is invoked
> - interrupt source is checked
> - if no notification is pending a signal is notificated for user space
> (or a process is marked runnable)
> - optionally our device interrupt generation is disabled
> - handler returns
> - interrupts are enabled

Then why bother ? Write a minimum conventional kernel driver implementing 
poll()

	Regards
		Oliver

Re: Is it useful to support user level drivers

[Pavel Machek]

Hi!

> > (i.e. counted). An alternative to queuing (user selectable) is to block
> > interrupt generation at hardware level in kernel space immediately
> > before notification.
> > 
> > I'm missing something?
> 
> IRQ 9 shared between user space app and disk. IRQ arrives is disabled and
> reported, app wakes up, app wants to page in code, IRQ is disabled,
> box dies

Actually, what about specifying that your usermode app has to be
pagelocked?

Alternatively.... You *can* do disk I/O without interrupts. Just poll
your IDE controller. [I'm doing that on my velo.] Hopefully your timer
IRQ is not shared with usermode app, then :-( [but that's almost
impossible on PCs, right?].
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: Is it useful to support user level drivers

[Alan Cox]

> Lastly an IRQ kernel module can disable_irq() from interrupt handler
> and enable it again only on explicit acknowledge from user.

No. The IRQ might be shared, and you get a slight problem if you just disabled
an IRQ needed to make progress for user space to handle the IRQ

Re: Is it useful to support user level drivers

[Matthias Urlichs]

At 14:28 +0100 2001-06-21, Alan Cox wrote:
>No. The IRQ might be shared, and you get a slight problem if you just disabled
>an IRQ needed to make progress for user space to handle the IRQ

Two choices:

- Disallow shared interrupts for usermode drivers.

- Make the 'generic interrupt handler device driver' configurable 
and/or module-extensible. You only need three entry points 
("Interrupt set?"/"Enable interrupts"/"Disable interrupts"), which is 
reasonably simple to get right.
-- 
Matthias Urlichs

Re: Is it useful to support user level drivers

[Pavel Machek]

Hi!

> >No. The IRQ might be shared, and you get a slight problem if you just disabled
> >an IRQ needed to make progress for user space to handle the IRQ
> 
> Two choices:
> 
> - Disallow shared interrupts for usermode drivers.

That's hard... If you your notebook comes with soundcard and ltmodem
sharing the irq, and ltmodem only has userspace driver, you are
screwed.
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: Is it useful to support user level drivers

[Dmitry A. Fedorov]

On Thu, 21 Jun 2001, Alan Cox wrote:

> > Lastly an IRQ kernel module can disable_irq() from interrupt handler
> > and enable it again only on explicit acknowledge from user.
> 
> No. The IRQ might be shared, and you get a slight problem if you just disabled
> an IRQ needed to make progress for user space to handle the IRQ

Disabling the IRQ till user acknowledge is an option for particular
device handling.
Yes, IRQ sharing is impossible with it and IRQ module must reject setup
requests with this option and SA_SHIRQ flag together.
However, it is important for rare cases only with "bad" devices
(their interrupt behaviour is really bad!) and IRQ sharing requirement.

Re: Is it useful to support user level drivers

[Dmitry A. Fedorov]

On Thu, 21 Jun 2001, Balbir Singh wrote:

> I realize that the Linux kernel supports user
> level drivers (via ioperm, etc). However interrupts
> at user level are not supported, does anyone think
> it would be a good idea to add user level interrupt
> support ? I have a framework for it, but it still
> needs
> a lot of work.

http://www.ibiblio.org/pub/Linux/kernel/irq-1.68.2.tar.gz
 ftp://ftp.inp.nsk.su/export/fedorov/soft/irq-1.68.2.tar.gz

(2.0.x - 2.2.x kernels)

kernel module to delivery hardware interrupts to user space
programs. Hardware interrupts (IRQ) are accessible by
character devices /dev/irq[0-15]. Interrupts delivered by
signals and select(2)/poll(2)

Re: Is it useful to support user level drivers

[john slee]

On Thu, Jun 21, 2001 at 06:38:09PM +0700, Dmitry A. Fedorov wrote:
> kernel module to delivery hardware interrupts to user space
> programs. Hardware interrupts (IRQ) are accessible by
> character devices /dev/irq[0-15]. Interrupts delivered by
> signals and select(2)/poll(2)

i believe libgpio uses the existing usb/iee1394/serial/parallel
interfaces to provide a limited userspace driver capability.  gphoto2
uses this to support a LOT of digital cameras entirely in userspace...

obviously this concept isn't covering everything but it sure covers a
lot of bases.  also depends on what you understand a "driver" to be...
from a "common user"'s perspective it just means "it makes my WinWidget
work!"

it's similar to what you describe above in that there's a kernel
interface, but it's more specific than /dev/irq5.  this is good in that
you don't want a different usb driver for every userspace usb device
driver...

http://sourceforge.net/projects/gphoto/ (i think)

j.

-- 
"Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson

Re: Is it useful to support user level drivers

[Matthias Urlichs]

At 23:50 +1000 2001-06-21, john slee wrote:
>i believe libgpio uses the existing usb/iee1394/serial/parallel
>interfaces to provide a limited userspace driver capability.

That only means, however, that the specific kernel drivers explicitly 
support mid-level usermode access.

They still handle the actual hardware state changes without usermode support.

-- 
Matthias Urlichs

Re: Is it useful to support user level drivers

[john slee]

On Thu, Jun 21, 2001 at 03:58:33PM +0200, Matthias Urlichs wrote:
> At 23:50 +1000 2001-06-21, john slee wrote:
> >i believe libgpio uses the existing usb/iee1394/serial/parallel
> >interfaces to provide a limited userspace driver capability.
> 
> That only means, however, that the specific kernel drivers explicitly
> support mid-level usermode access.
> 
> They still handle the actual hardware state changes without usermode support.

yes, that was the point.  while it might be a stretch of the "mechanism,
not policy" argument, i like having drivers organized this way.  it
makes a lot of sense for hotpluggable things like usb.

j.

-- 
"Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson

Re: Is it useful to support user level drivers

[Pavel Machek]

Hi!

> I realize that the Linux kernel supports user
> level drivers (via ioperm, etc). However interrupts
> at user level are not supported, does anyone think
> it would be a good idea to add user level interrupt
> support ? I have a framework for it, but it still
> needs
> a lot of work.
> 
> Depending on the response I get, I can send out
> more email. Please cc me to the replies as I am no
> longer a part of the Linux kernel mailing list - due
> to the humble size of my mail box.

I'd like to see that done for userspace ltmodem
driver... Unfortunately it can not be easily done for shared PCI
interrupts.
								Pavel
PS: Next needed thing is to make it possible for usermode driver to
"mimic" kernel one, including ioctls.
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: Is it useful to support user level drivers

[Pete Zaitcev]

> There is no such thing as a "user mode" interrupt service routine.
> There never was one, and there will never be one on any machine
> that fetches instructions from memory for execution. [...]

If memory does not deceive me, SunLab Spring processed interrupts
in user space. I do not remember for sure, but I think QNX did, too.
User mode interrupt handlers are perfectly doable, provided that the
hardware allows to mask interrupts selectively.

Large part of the post that I quoted was spent on spitting
in the general direction of clueless programmers; indeed,
I observe that perhaps 90% of requests for user mode interrupt
processing come from the same people who would like to write
Linux kernel mode code in C++ (total retards, in other words).

It does not mean, however, that there are not justified cases
for user-mode interrupt handlers, especially outside of Linux.
Some OSes are even written in C++ and Java, and run just fine
on a machine that fetches instructions from memory.

-- Pete

Re: Is it useful to support user level drivers

[Richard B. Johnson]

On Thu, 21 Jun 2001, Pete Zaitcev wrote:

> > There is no such thing as a "user mode" interrupt service routine.
> > There never was one, and there will never be one on any machine
> > that fetches instructions from memory for execution. [...]
> 
> If memory does not deceive me, SunLab Spring processed interrupts
> in user space. I do not remember for sure, but I think QNX did, too.
> User mode interrupt handlers are perfectly doable, provided that the
> hardware allows to mask interrupts selectively.
>

QNX does not have any difference between user-space and kernel space.
It's not paged-virtual. It's just one big sheet of address space
with no memory protection (everything is shared). All procedures
to be executed are known at compile time.

Therefore, any piece of code can do anything it wants including
handling hardware directly. In fact, that's what QNX was designed
for.
 
> Large part of the post that I quoted was spent on spitting
> in the general direction of clueless programmers; indeed,
> I observe that perhaps 90% of requests for user mode interrupt
> processing come from the same people who would like to write
> Linux kernel mode code in C++ (total retards, in other words).
> 

I think I said (or implied) that too.

> It does not mean, however, that there are not justified cases
> for user-mode interrupt handlers, especially outside of Linux.

Not if that memory can get swapped or paged out .


> Some OSes are even written in C++ and Java, and run just fine
> on a machine that fetches instructions from memory.
> 

Then you are stretching the meaning of "OS" just a bit. It's
true that I can make an Operating System  entirely in interpreted
BASIC. However, it is really only a "Command Processor" even
though it can have multiple "connections" requesting commands
to be processed.


> -- Pete
> -

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: Is it useful to support user level drivers

[Anders Larsen]

"Richard B. Johnson" wrote:
> 
> QNX does not have any difference between user-space and kernel space.
> It's not paged-virtual. It's just one big sheet of address space
> with no memory protection (everything is shared). All procedures
> to be executed are known at compile time.

That's completely, utterly untrue.
QNX does indeed sport paged-virtual memory with memory protection;
(although QNX4 does not support swap).

User-mode interrupts are standard procedure; the deadlock problems
Alan has mentioned do not apply, since any running process is
always resident in memory.
Shared regions have to be explicitly created; access is *not* open
to anybody.

Nothing has to be known at "compile time"; QNX is a full-featured
OS with dynamic loading.

> Therefore, any piece of code can do anything it wants including
> handling hardware directly.

Again not true; only privileged processes can enter kernel mode
to execute port I/O instructions directly.

cheers
Anders
-- 
"In theory there is no difference between theory and practice.
 In practice there is." - Yogi Berra

Re: Is it useful to support user level drivers

[Richard B. Johnson]

On Fri, 22 Jun 2001, Anders Larsen wrote:

> "Richard B. Johnson" wrote:
> > 
> > QNX does not have any difference between user-space and kernel space.
> > It's not paged-virtual. It's just one big sheet of address space
> > with no memory protection (everything is shared). All procedures
> > to be executed are known at compile time.
> 
> That's completely, utterly untrue.
> QNX does indeed sport paged-virtual memory with memory protection;
> (although QNX4 does not support swap).

Then QNX is not the QNX that I have used.

> 
> User-mode interrupts are standard procedure; the deadlock problems
> Alan has mentioned do not apply, since any running process is
> always resident in memory.
> Shared regions have to be explicitly created; access is *not* open
> to anybody.
> 
> Nothing has to be known at "compile time"; QNX is a full-featured
> OS with dynamic loading.
>

The QNX that I have used, advertised as QNX, and been around since
32-bit ix86 was available, is EXACTLY as I stated.

 
> > Therefore, any piece of code can do anything it wants including
> > handling hardware directly.
> 
> Again not true; only privileged processes can enter kernel mode
> to execute port I/O instructions directly.
> 

The QNX that I have used, again is EXACTLY as stated.

> cheers
> Anders

If you have used a different QNX, then QNX has either changed
radically, or is a different company/QNX than what I used.
And, I had a lot of good experiences with it since standard
I/O was provided, as was boot, but it was an open book otherwise
in which you were not prevented from doing anything you wanted
to do, at any instant you wanted to do it.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: Is it useful to support user level drivers

[Anders Larsen]

"Richard B. Johnson" wrote:
> 
> On Fri, 22 Jun 2001, Anders Larsen wrote:
> 
> > "Richard B. Johnson" wrote:
> > >
> > > QNX does not have any difference between user-space and kernel space.
> > > It's not paged-virtual. It's just one big sheet of address space
> > > with no memory protection (everything is shared). All procedures
> > > to be executed are known at compile time.
> >
> > That's completely, utterly untrue.
> > QNX does indeed sport paged-virtual memory with memory protection;
> > (although QNX4 does not support swap).
> 
> Then QNX is not the QNX that I have used.

Or you haven't used it recently (= within the past 10 years)

> > User-mode interrupts are standard procedure; the deadlock problems
> > Alan has mentioned do not apply, since any running process is
> > always resident in memory.
> > Shared regions have to be explicitly created; access is *not* open
> > to anybody.
> >
> > Nothing has to be known at "compile time"; QNX is a full-featured
> > OS with dynamic loading.
> >
> 
> The QNX that I have used, advertised as QNX, and been around since
> 32-bit ix86 was available, is EXACTLY as I stated.

Dynamic loading of executables has been in QNX for as long as I know
it (fifteen years).
With the appearance of QNX version 4 some ten years ago came 32-bit
address space, full memory management/protection etc.

> > > Therefore, any piece of code can do anything it wants including
> > > handling hardware directly.
> >
> > Again not true; only privileged processes can enter kernel mode
> > to execute port I/O instructions directly.
> 
> The QNX that I have used, again is EXACTLY as stated.

It must have been an early QNX version 2, then.
QNX 2 did not have any memory protection.

> If you have used a different QNX, then QNX has either changed
> radically, or is a different company/QNX than what I used.
> And, I had a lot of good experiences with it since standard
> I/O was provided, as was boot, but it was an open book otherwise
> in which you were not prevented from doing anything you wanted
> to do, at any instant you wanted to do it.

Of course QNX has changes radically over the decades (it's been
around for some twenty years now); what I frowned at was that
you made your statements as if they would apply to the *current*
state of affairs, which they certainly do not.

cheers
Anders
-- 
"In theory there is no difference between theory and practice.
 In practice there is." - Yogi Berra

Re: Is it useful to support user level drivers

[David S. Miller]

Pete Zaitcev writes:
 > If memory does not deceive me, SunLab Spring processed interrupts
 > in user space. I do not remember for sure, but I think QNX did, too.
 > User mode interrupt handlers are perfectly doable, provided that the
 > hardware allows to mask interrupts selectively.

SGI's IRIX does it too, for graphics card interrupts like "VBLANK" and
"rendering pipeline FIFO not full anymore".

Later,
David S. Miller
davem@redhat.com

Re: Is it useful to support user level drivers

[Mike Mackovitch]

On Thu, Jun 21, 2001 at 03:20:12PM -0700, David S. Miller wrote:
> 
> Pete Zaitcev writes:
>  > If memory does not deceive me, SunLab Spring processed interrupts
>  > in user space. I do not remember for sure, but I think QNX did, too.
>  > User mode interrupt handlers are perfectly doable, provided that the
>  > hardware allows to mask interrupts selectively.
> 
> SGI's IRIX does it too, for graphics card interrupts like "VBLANK" and
> "rendering pipeline FIFO not full anymore".

Sorry, but SGI's IRIX does NOT handle graphics interrupts in user space.

--macko
SGI Graphics Kernel Engineer 1994-1999

Re: Is it useful to support user level drivers

[David S. Miller]

Mike Mackovitch writes:
 > Sorry, but SGI's IRIX does NOT handle graphics interrupts in user space.

What the heck is ULI then?  I've actually read the assembly code for
this back when I did my SGI internship.

Later,
David S. Miller
davem@redhat.com

Re: Is it useful to support user level drivers

[Mike Mackovitch]

On Thu, Jun 21, 2001 at 04:22:32PM -0700, David S. Miller wrote:
> 
> Mike Mackovitch writes:
>  > Sorry, but SGI's IRIX does NOT handle graphics interrupts in user space.
> 
> What the heck is ULI then?  I've actually read the assembly code for
> this back when I did my SGI internship.

If my memory serves me correctly, I believe ULI was some
hacked up "user-level interrupt" feature.  I have no idea
who (if anyone) used it, but it definitely wasn't used by
SGI's graphics drivers.

--macko

Re: Is it useful to support user level drivers

[David S. Miller]

Mike Mackovitch writes:
 > On Thu, Jun 21, 2001 at 04:22:32PM -0700, David S. Miller wrote:
 > > What the heck is ULI then?  I've actually read the assembly code for
 > > this back when I did my SGI internship.
 > 
 > If my memory serves me correctly, I believe ULI was some
 > hacked up "user-level interrupt" feature.  I have no idea
 > who (if anyone) used it, but it definitely wasn't used by
 > SGI's graphics drivers.

Strange, because taking veritcal retrace interrupts directly in
userspace was the first thing that came to my mind when I saw
what ULI was doing.

When IRIX optimizes something to the extreme, it is either for
big-iron or graphics performance, very few exceptions exist :-)

Later,
David S. Miller
davem@redhat.com