Messages in this thread | | | Date | Tue, 15 Mar 2005 14:47:42 +1100 | From | Peter Chubb <> | Subject | Re: User mode drivers: part 1, interrupt handling (patch for 2.6.11) |
| |
>>>>> "Jon" == Jon Smirl <jonsmirl@gmail.com> writes:
Jon> On Mon, 14 Mar 2005 12:42:27 +1100, Peter Chubb Jon> <peterc@gelato.unsw.edu.au> wrote: >> >>>>> "Jon" == Jon Smirl <jonsmirl@gmail.com> writes: >> >> >> The scenario I'm thinking about with these patches are things >> like >> low-latency user-level networking between nodes in a >> cluster, where >> for good performance even with a kernel driver >> you don't want to >> share your interrupt line with anything else. >> Jon> The code needs to refuse to install if the IRQ line is shared. >> It does. The request_irq() call explicitly does not include >> SA_SHARED in its flags, so if the line is shared, it'll return an >> error to user space when the driver tries to open the file >> representing the interrupt.
Jon> Please put some big comments warning people about adding Jon> SA_SHARED. I can easily see someone thinking that they are fixing Jon> a bug by adding it. I'd probably even write a paragraph about Jon> what will happen if SA_SHARED is added.
Will do. The main problem here is X86, as other architectures either don't care, or have enough interrupt lines. And the people who are paying me for this kind of thing all run IA64....
What I really want to do is deprivilege the driver code as much as possible. Whatever a driver does, the rest of the system should keep going. That way malicious or buggy drivers can only affect the processes that are trying to use the device they manage. Moreover, it should be possible to kill -9 a driver, then restart it, without the rest of the system noticing more than a hiccup. To do this, step one is to run the driver in user space, so that it's subject to the same resource management control as any other process. Step two, which is a lot harder, is to connect the driver back into the kernel so that it can be shared. Tun/Tap can be used for network devices, but it's really too slow -- you need zero-copy and shared notification.
-- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au The technical we do immediately, the political takes *forever* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |