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
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
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.
>
> De
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
"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 (ev
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 pe
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 ch
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 b
"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 completel
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 proc
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
> 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 fo
> 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 interr
"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
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 sha
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 a
> (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 w
"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 le
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 t
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 deli
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 us
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 devic
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
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 t
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 us
> 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
-
To unsubscribe fro
> 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 c
> > 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 po
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 o
--- Alan Cox <[EMAIL PROTECTED]> 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 someth
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 s
> 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 spa
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 framewo
33 matches
Mail list logo
