Re: Is it useful to support user level drivers
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 [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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 [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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 [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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 [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
"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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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" <[EMAIL PROTECTED]> 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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
"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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
"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:[EMAIL PROTECTED] 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! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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:[EMAIL PROTECTED] 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! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
> (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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
"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:[EMAIL PROTECTED] 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! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
> 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
> > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
--- 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 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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it useful to support user level drivers
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. */ PGP signature
Is it useful to support user level drivers
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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
