* Is it useful to support user level drivers @ 2001-06-21 10:41 Balbir Singh 2001-06-21 10:55 ` Tim Waugh ` (3 more replies) 0 siblings, 4 replies; 38+ messages in thread From: Balbir Singh @ 2001-06-21 10:41 UTC (permalink / raw) To: linux-kernel 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/ ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 10:41 Is it useful to support user level drivers Balbir Singh @ 2001-06-21 10:55 ` Tim Waugh 2001-06-21 11:04 ` Alan Cox ` (2 subsequent siblings) 3 siblings, 0 replies; 38+ messages in thread From: Tim Waugh @ 2001-06-21 10:55 UTC (permalink / raw) To: Balbir Singh; +Cc: linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 10:41 Is it useful to support user level drivers Balbir Singh 2001-06-21 10:55 ` Tim Waugh @ 2001-06-21 11:04 ` Alan Cox 2001-06-21 12:43 ` Balbir Singh 2001-06-21 12:45 ` Dmitry A. Fedorov 2001-06-21 11:38 ` Dmitry A. Fedorov 2001-06-28 22:51 ` Pavel Machek 3 siblings, 2 replies; 38+ messages in thread From: Alan Cox @ 2001-06-21 11:04 UTC (permalink / raw) To: Balbir Singh; +Cc: linux-kernel > 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 11:04 ` Alan Cox @ 2001-06-21 12:43 ` Balbir Singh 2001-06-21 13:27 ` Alan Cox 2001-06-28 22:52 ` Pavel Machek 2001-06-21 12:45 ` Dmitry A. Fedorov 1 sibling, 2 replies; 38+ messages in thread From: Balbir Singh @ 2001-06-21 12:43 UTC (permalink / raw) To: Alan Cox; +Cc: linux-kernel --- 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/ ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 12:43 ` Balbir Singh @ 2001-06-21 13:27 ` Alan Cox 2001-06-28 22:52 ` Pavel Machek 1 sibling, 0 replies; 38+ messages in thread From: Alan Cox @ 2001-06-21 13:27 UTC (permalink / raw) To: Balbir Singh; +Cc: Alan Cox, linux-kernel > 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 12:43 ` Balbir Singh 2001-06-21 13:27 ` Alan Cox @ 2001-06-28 22:52 ` Pavel Machek 1 sibling, 0 replies; 38+ messages in thread From: Pavel Machek @ 2001-06-28 22:52 UTC (permalink / raw) To: Balbir Singh, Alan Cox; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 11:04 ` Alan Cox 2001-06-21 12:43 ` Balbir Singh @ 2001-06-21 12:45 ` Dmitry A. Fedorov 2001-06-21 13:24 ` Oliver Neukum 2001-06-21 13:28 ` Alan Cox 1 sibling, 2 replies; 38+ messages in thread From: Dmitry A. Fedorov @ 2001-06-21 12:45 UTC (permalink / raw) To: Alan Cox; +Cc: Balbir Singh, linux-kernel 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 12:45 ` Dmitry A. Fedorov @ 2001-06-21 13:24 ` Oliver Neukum 2001-06-21 14:46 ` Dmitry A. Fedorov 2001-06-21 13:28 ` Alan Cox 1 sibling, 1 reply; 38+ messages in thread From: Oliver Neukum @ 2001-06-21 13:24 UTC (permalink / raw) To: Dmitry A. Fedorov, Alan Cox; +Cc: Balbir Singh, linux-kernel > > 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 13:24 ` Oliver Neukum @ 2001-06-21 14:46 ` Dmitry A. Fedorov 2001-06-21 15:19 ` Oliver Neukum 2001-06-21 16:34 ` Abramo Bagnara 0 siblings, 2 replies; 38+ messages in thread From: Dmitry A. Fedorov @ 2001-06-21 14:46 UTC (permalink / raw) To: Oliver Neukum; +Cc: Balbir Singh, linux-kernel 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 14:46 ` Dmitry A. Fedorov @ 2001-06-21 15:19 ` Oliver Neukum 2001-06-22 4:19 ` Dmitry A. Fedorov 2001-06-21 16:34 ` Abramo Bagnara 1 sibling, 1 reply; 38+ messages in thread From: Oliver Neukum @ 2001-06-21 15:19 UTC (permalink / raw) To: Dmitry A. Fedorov; +Cc: Balbir Singh, linux-kernel 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 15:19 ` Oliver Neukum @ 2001-06-22 4:19 ` Dmitry A. Fedorov 2001-06-22 7:28 ` Balbir Singh 0 siblings, 1 reply; 38+ messages in thread From: Dmitry A. Fedorov @ 2001-06-22 4:19 UTC (permalink / raw) To: Oliver Neukum; +Cc: Balbir Singh, Richard B. Johnson, Alan Cox, linux-kernel 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-22 4:19 ` Dmitry A. Fedorov @ 2001-06-22 7:28 ` Balbir Singh 0 siblings, 0 replies; 38+ messages in thread From: Balbir Singh @ 2001-06-22 7:28 UTC (permalink / raw) To: D.A.Fedorov, Oliver Neukum Cc: Balbir Singh, Richard B. Johnson, Alan Cox, linux-kernel 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/ ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 14:46 ` Dmitry A. Fedorov 2001-06-21 15:19 ` Oliver Neukum @ 2001-06-21 16:34 ` Abramo Bagnara 2001-06-21 17:27 ` Alan Cox 1 sibling, 1 reply; 38+ messages in thread From: Abramo Bagnara @ 2001-06-21 16:34 UTC (permalink / raw) To: D.A.Fedorov; +Cc: Oliver Neukum, Balbir Singh, linux-kernel "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! ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 16:34 ` Abramo Bagnara @ 2001-06-21 17:27 ` Alan Cox 2001-06-21 19:59 ` Abramo Bagnara 2001-06-28 22:57 ` Pavel Machek 0 siblings, 2 replies; 38+ messages in thread From: Alan Cox @ 2001-06-21 17:27 UTC (permalink / raw) To: Abramo Bagnara; +Cc: D.A.Fedorov, Oliver Neukum, Balbir Singh, linux-kernel > (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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 17:27 ` Alan Cox @ 2001-06-21 19:59 ` Abramo Bagnara 2001-06-21 20:40 ` Richard B. Johnson 2001-06-21 21:09 ` Oliver Neukum 2001-06-28 22:57 ` Pavel Machek 1 sibling, 2 replies; 38+ messages in thread From: Abramo Bagnara @ 2001-06-21 19:59 UTC (permalink / raw) To: Alan Cox; +Cc: D.A.Fedorov, Oliver Neukum, Balbir Singh, linux-kernel 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! ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 19:59 ` Abramo Bagnara @ 2001-06-21 20:40 ` Richard B. Johnson 2001-06-21 20:54 ` Abramo Bagnara 2001-06-21 21:09 ` Oliver Neukum 1 sibling, 1 reply; 38+ messages in thread From: Richard B. Johnson @ 2001-06-21 20:40 UTC (permalink / raw) To: Abramo Bagnara Cc: Alan Cox, D.A.Fedorov, Oliver Neukum, Balbir Singh, linux-kernel 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 20:40 ` Richard B. Johnson @ 2001-06-21 20:54 ` Abramo Bagnara 0 siblings, 0 replies; 38+ messages in thread From: Abramo Bagnara @ 2001-06-21 20:54 UTC (permalink / raw) To: root; +Cc: Alan Cox, D.A.Fedorov, Oliver Neukum, Balbir Singh, linux-kernel "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! ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 19:59 ` Abramo Bagnara 2001-06-21 20:40 ` Richard B. Johnson @ 2001-06-21 21:09 ` Oliver Neukum 1 sibling, 0 replies; 38+ messages in thread From: Oliver Neukum @ 2001-06-21 21:09 UTC (permalink / raw) To: Abramo Bagnara, Alan Cox Cc: D.A.Fedorov@inp.nsk.su Balbir Singh, linux-kernel > 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 17:27 ` Alan Cox 2001-06-21 19:59 ` Abramo Bagnara @ 2001-06-28 22:57 ` Pavel Machek 1 sibling, 0 replies; 38+ messages in thread From: Pavel Machek @ 2001-06-28 22:57 UTC (permalink / raw) To: Alan Cox, Abramo Bagnara Cc: D.A.Fedorov, Oliver Neukum, Balbir Singh, linux-kernel 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 12:45 ` Dmitry A. Fedorov 2001-06-21 13:24 ` Oliver Neukum @ 2001-06-21 13:28 ` Alan Cox 2001-06-21 14:03 ` Matthias Urlichs 2001-06-21 14:20 ` Dmitry A. Fedorov 1 sibling, 2 replies; 38+ messages in thread From: Alan Cox @ 2001-06-21 13:28 UTC (permalink / raw) To: D.A.Fedorov; +Cc: Alan Cox, Balbir Singh, linux-kernel > 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 13:28 ` Alan Cox @ 2001-06-21 14:03 ` Matthias Urlichs 2001-06-28 22:54 ` Pavel Machek 2001-06-21 14:20 ` Dmitry A. Fedorov 1 sibling, 1 reply; 38+ messages in thread From: Matthias Urlichs @ 2001-06-21 14:03 UTC (permalink / raw) To: Alan Cox, D.A.Fedorov; +Cc: Alan Cox, Balbir Singh, linux-kernel 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 14:03 ` Matthias Urlichs @ 2001-06-28 22:54 ` Pavel Machek 0 siblings, 0 replies; 38+ messages in thread From: Pavel Machek @ 2001-06-28 22:54 UTC (permalink / raw) To: Matthias Urlichs, Alan Cox, D.A.Fedorov; +Cc: Balbir Singh, linux-kernel 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 13:28 ` Alan Cox 2001-06-21 14:03 ` Matthias Urlichs @ 2001-06-21 14:20 ` Dmitry A. Fedorov 1 sibling, 0 replies; 38+ messages in thread From: Dmitry A. Fedorov @ 2001-06-21 14:20 UTC (permalink / raw) To: Alan Cox; +Cc: Balbir Singh, linux-kernel 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 10:41 Is it useful to support user level drivers Balbir Singh 2001-06-21 10:55 ` Tim Waugh 2001-06-21 11:04 ` Alan Cox @ 2001-06-21 11:38 ` Dmitry A. Fedorov 2001-06-21 13:50 ` john slee 2001-06-28 22:51 ` Pavel Machek 3 siblings, 1 reply; 38+ messages in thread From: Dmitry A. Fedorov @ 2001-06-21 11:38 UTC (permalink / raw) To: Balbir Singh; +Cc: linux-kernel 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) ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 11:38 ` Dmitry A. Fedorov @ 2001-06-21 13:50 ` john slee 2001-06-21 13:58 ` Matthias Urlichs 0 siblings, 1 reply; 38+ messages in thread From: john slee @ 2001-06-21 13:50 UTC (permalink / raw) To: Dmitry A. Fedorov; +Cc: Balbir Singh, linux-kernel 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 13:50 ` john slee @ 2001-06-21 13:58 ` Matthias Urlichs 2001-06-21 14:21 ` john slee 0 siblings, 1 reply; 38+ messages in thread From: Matthias Urlichs @ 2001-06-21 13:58 UTC (permalink / raw) To: john slee, Dmitry A. Fedorov; +Cc: Balbir Singh, linux-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 the actual hardware state changes without usermode support. -- Matthias Urlichs ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 13:58 ` Matthias Urlichs @ 2001-06-21 14:21 ` john slee 0 siblings, 0 replies; 38+ messages in thread From: john slee @ 2001-06-21 14:21 UTC (permalink / raw) To: Matthias Urlichs; +Cc: Dmitry A. Fedorov, Balbir Singh, linux-kernel 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 10:41 Is it useful to support user level drivers Balbir Singh ` (2 preceding siblings ...) 2001-06-21 11:38 ` Dmitry A. Fedorov @ 2001-06-28 22:51 ` Pavel Machek 3 siblings, 0 replies; 38+ messages in thread From: Pavel Machek @ 2001-06-28 22:51 UTC (permalink / raw) To: Balbir Singh, linux-kernel 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
[parent not found: <mailman.993156181.18994.linux-kernel2news@redhat.com>]
* Re: Is it useful to support user level drivers [not found] <mailman.993156181.18994.linux-kernel2news@redhat.com> @ 2001-06-21 22:06 ` Pete Zaitcev 2001-06-21 23:40 ` Richard B. Johnson 2001-06-21 22:20 ` David S. Miller 1 sibling, 1 reply; 38+ messages in thread From: Pete Zaitcev @ 2001-06-21 22:06 UTC (permalink / raw) To: root; +Cc: linux-kernel > 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 22:06 ` Pete Zaitcev @ 2001-06-21 23:40 ` Richard B. Johnson 2001-06-22 0:30 ` Anders Larsen 0 siblings, 1 reply; 38+ messages in thread From: Richard B. Johnson @ 2001-06-21 23:40 UTC (permalink / raw) To: Pete Zaitcev; +Cc: linux-kernel 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 23:40 ` Richard B. Johnson @ 2001-06-22 0:30 ` Anders Larsen 2001-06-22 0:43 ` Richard B. Johnson 0 siblings, 1 reply; 38+ messages in thread From: Anders Larsen @ 2001-06-22 0:30 UTC (permalink / raw) To: Richard B. Johnson; +Cc: linux-kernel "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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-22 0:30 ` Anders Larsen @ 2001-06-22 0:43 ` Richard B. Johnson 2001-06-25 0:06 ` Anders Larsen 0 siblings, 1 reply; 38+ messages in thread From: Richard B. Johnson @ 2001-06-22 0:43 UTC (permalink / raw) To: Anders Larsen; +Cc: linux-kernel 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-22 0:43 ` Richard B. Johnson @ 2001-06-25 0:06 ` Anders Larsen 0 siblings, 0 replies; 38+ messages in thread From: Anders Larsen @ 2001-06-25 0:06 UTC (permalink / raw) To: Richard B. Johnson; +Cc: linux-kernel "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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers [not found] <mailman.993156181.18994.linux-kernel2news@redhat.com> 2001-06-21 22:06 ` Pete Zaitcev @ 2001-06-21 22:20 ` David S. Miller 2001-06-21 23:09 ` Mike Mackovitch 2001-06-21 23:22 ` David S. Miller 1 sibling, 2 replies; 38+ messages in thread From: David S. Miller @ 2001-06-21 22:20 UTC (permalink / raw) To: Pete Zaitcev; +Cc: root, linux-kernel 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 22:20 ` David S. Miller @ 2001-06-21 23:09 ` Mike Mackovitch 2001-06-21 23:22 ` David S. Miller 1 sibling, 0 replies; 38+ messages in thread From: Mike Mackovitch @ 2001-06-21 23:09 UTC (permalink / raw) To: David S. Miller; +Cc: Pete Zaitcev, root, linux-kernel 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 22:20 ` David S. Miller 2001-06-21 23:09 ` Mike Mackovitch @ 2001-06-21 23:22 ` David S. Miller 2001-06-21 23:50 ` Mike Mackovitch 2001-06-22 0:36 ` David S. Miller 1 sibling, 2 replies; 38+ messages in thread From: David S. Miller @ 2001-06-21 23:22 UTC (permalink / raw) To: Mike Mackovitch; +Cc: Pete Zaitcev, root, linux-kernel 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 23:22 ` David S. Miller @ 2001-06-21 23:50 ` Mike Mackovitch 2001-06-22 0:36 ` David S. Miller 1 sibling, 0 replies; 38+ messages in thread From: Mike Mackovitch @ 2001-06-21 23:50 UTC (permalink / raw) To: David S. Miller; +Cc: Mike Mackovitch, Pete Zaitcev, root, linux-kernel 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Is it useful to support user level drivers 2001-06-21 23:22 ` David S. Miller 2001-06-21 23:50 ` Mike Mackovitch @ 2001-06-22 0:36 ` David S. Miller 1 sibling, 0 replies; 38+ messages in thread From: David S. Miller @ 2001-06-22 0:36 UTC (permalink / raw) To: Mike Mackovitch; +Cc: Pete Zaitcev, root, linux-kernel 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2001-06-29 18:02 UTC | newest] Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-06-21 10:41 Is it useful to support user level drivers Balbir Singh 2001-06-21 10:55 ` Tim Waugh 2001-06-21 11:04 ` Alan Cox 2001-06-21 12:43 ` Balbir Singh 2001-06-21 13:27 ` Alan Cox 2001-06-28 22:52 ` Pavel Machek 2001-06-21 12:45 ` Dmitry A. Fedorov 2001-06-21 13:24 ` Oliver Neukum 2001-06-21 14:46 ` Dmitry A. Fedorov 2001-06-21 15:19 ` Oliver Neukum 2001-06-22 4:19 ` Dmitry A. Fedorov 2001-06-22 7:28 ` Balbir Singh 2001-06-21 16:34 ` Abramo Bagnara 2001-06-21 17:27 ` Alan Cox 2001-06-21 19:59 ` Abramo Bagnara 2001-06-21 20:40 ` Richard B. Johnson 2001-06-21 20:54 ` Abramo Bagnara 2001-06-21 21:09 ` Oliver Neukum 2001-06-28 22:57 ` Pavel Machek 2001-06-21 13:28 ` Alan Cox 2001-06-21 14:03 ` Matthias Urlichs 2001-06-28 22:54 ` Pavel Machek 2001-06-21 14:20 ` Dmitry A. Fedorov 2001-06-21 11:38 ` Dmitry A. Fedorov 2001-06-21 13:50 ` john slee 2001-06-21 13:58 ` Matthias Urlichs 2001-06-21 14:21 ` john slee 2001-06-28 22:51 ` Pavel Machek [not found] <mailman.993156181.18994.linux-kernel2news@redhat.com> 2001-06-21 22:06 ` Pete Zaitcev 2001-06-21 23:40 ` Richard B. Johnson 2001-06-22 0:30 ` Anders Larsen 2001-06-22 0:43 ` Richard B. Johnson 2001-06-25 0:06 ` Anders Larsen 2001-06-21 22:20 ` David S. Miller 2001-06-21 23:09 ` Mike Mackovitch 2001-06-21 23:22 ` David S. Miller 2001-06-21 23:50 ` Mike Mackovitch 2001-06-22 0:36 ` David S. Miller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).