From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Chubb
> > "Jon" == Jon Smirl <[EMAIL PROTECTED]> 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 perfor
On Maw, 2005-03-15 at 04:32, Lee Revell wrote:
> This seems sufficient for the simplest devices, that just have an
> IRQ_PENDING and an IRQ_ACK register. But what about a device like the
> emu10k1 where you have a half loop and loop interrupt for each of 64
> channels, plus about 10 other interrup
On Sat, 2005-03-12 at 21:03 -0500, Jon Smirl wrote:
> On Fri, 11 Mar 2005 19:14:13 +, Alan Cox <[EMAIL PROTECTED]> wrote:
> > I posted a proposal for this sometime ago because X has some uses for
> > it. The idea being you'd pass a struct that describes
> >
> > 1. What tells you an IRQ oc
> "Jon" == Jon Smirl <[EMAIL PROTECTED]> writes:
Jon> On Tue, 15 Mar 2005 14:47:42 +1100, Peter Chubb
Jon> <[EMAIL PROTECTED]> wrote:
>> 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 w
On Tue, 15 Mar 2005 14:47:42 +1100, Peter Chubb
<[EMAIL PROTECTED]> wrote:
> 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
> "Jon" == Jon Smirl <[EMAIL PROTECTED]> writes:
Jon> On Mon, 14 Mar 2005 12:42:27 +1100, Peter Chubb
Jon> <[EMAIL PROTECTED]> wrote:
>> > "Jon" == Jon Smirl <[EMAIL PROTECTED]> writes:
>>
>> >> The scenario I'm thinking about with these patches are things
>> like >> low-latency user-leve
On Mon, 14 Mar 2005 12:42:27 +1100, Peter Chubb
<[EMAIL PROTECTED]> wrote:
> > "Jon" == Jon Smirl <[EMAIL PROTECTED]> 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 perfor
On Mon, 14 Mar 2005 13:33:31 +, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Llu, 2005-03-14 at 00:02, Peter Chubb wrote:
> > I can see there'd be problems if the code allowed shared interrupts,
> > but it doesn't.
>
> If you don't allow shared IRQ's its useless, if you do allow shared
> IRQ's it
On Llu, 2005-03-14 at 00:02, Peter Chubb wrote:
> I can see there'd be problems if the code allowed shared interrupts,
> but it doesn't.
If you don't allow shared IRQ's its useless, if you do allow shared
IRQ's it deadlocks. Take your pick 8)
As to your comment about needing to do a few more I/O
On Mon, 14 Mar 2005 12:42:27 +1100, Peter Chubb
<[EMAIL PROTECTED]> wrote:
> > "Jon" == Jon Smirl <[EMAIL PROTECTED]> 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 perfor
On Sat, 12 Mar 2005 10:11:18 -0700 (MST), Zwane Mwaikambo
<[EMAIL PROTECTED]> wrote:
> Alan's proposal sounds very plausible and additionally if we find that
> we have an irq line screaming we could use the same supplied information
> to disable userspace interrupt handled devices first.
I like it
> "Jon" == Jon Smirl <[EMAIL PROTECTED]> writes:
Jon> On Mon, 14 Mar 2005 12:42:27 +1100, Peter Chubb
Jon> <[EMAIL PROTECTED]> wrote:
>> > "Jon" == Jon Smirl <[EMAIL PROTECTED]> writes:
>>
>> >> The scenario I'm thinking about with these patches are things
>> like >> low-latency user-leve
> "Jon" == Jon Smirl <[EMAIL PROTECTED]> writes:
Jon> On Sat, 12 Mar 2005 10:11:18 -0700 (MST), Zwane Mwaikambo
Jon> <[EMAIL PROTECTED]> wrote:
>> Alan's proposal sounds very plausible and additionally if we find
>> that we have an irq line screaming we could use the same supplied
>> informati
On Mon, 14 Mar 2005 11:39:00 +1100, Peter Chubb
<[EMAIL PROTECTED]> wrote:
> > "Jon" == Jon Smirl <[EMAIL PROTECTED]> writes:
>
> Jon> On Fri, 11 Mar 2005 11:29:20 +0100, Pavel Machek <[EMAIL PROTECTED]>
> Jon> wrote:
> >> Hi!
> >>
> >> > As many of you will be aware, we've been working on
> >
> "Jon" == Jon Smirl <[EMAIL PROTECTED]> 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 a
> "Jon" == Jon Smirl <[EMAIL PROTECTED]> writes:
Jon> On Fri, 11 Mar 2005 11:29:20 +0100, Pavel Machek <[EMAIL PROTECTED]>
Jon> wrote:
>> Hi!
>>
>> > As many of you will be aware, we've been working on
>> infrastructure for > user-mode PCI and other drivers. The first
>> step is to be able t
> "Jon" == Jon Smirl <[EMAIL PROTECTED]> writes:
Jon> On Fri, 11 Mar 2005 14:36:10 +1100, Peter Chubb
Jon> <[EMAIL PROTECTED]> wrote:
>> As many of you will be aware, we've been working on infrastructure
>> for user-mode PCI and other drivers. The first step is to be able
>> to handle interr
On Gwe, 2005-03-11 at 03:36, Peter Chubb wrote:
> +static irqreturn_t irq_proc_irq_handler(int irq, void *vidp, struct pt_regs
> *regs)
> +{
> + struct irq_proc *idp = (struct irq_proc *)vidp;
> +
> + BUG_ON(idp->irq != irq);
> + disable_irq_nosync(irq);
> + atomic_inc(&idp->coun
On Fri, 11 Mar 2005 19:14:13 +, Alan Cox <[EMAIL PROTECTED]> wrote:
> I posted a proposal for this sometime ago because X has some uses for
> it. The idea being you'd pass a struct that describes
>
> 1. What tells you an IRQ occurred on this device
> 2. How to clear it
> 3. How
On Sat, 12 Mar 2005 11:27:25 -0500, Jon Smirl <[EMAIL PROTECTED]> wrote:
> Xen just posted patches for using kgdb between two instances but I
> don't see how they get out of the interrupt acknowledge problem
> either.
I just talked to the Xen people. They don't have a solution either.
They did poi
On Sat, 12 Mar 2005, Jon Smirl wrote:
> On Fri, 11 Mar 2005 14:36:10 +1100, Peter Chubb
> <[EMAIL PROTECTED]> wrote:
> >
> > As many of you will be aware, we've been working on infrastructure for
> > user-mode PCI and other drivers. The first step is to be able to
> > handle interrupts from user
On Fri, 11 Mar 2005 11:29:20 +0100, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > As many of you will be aware, we've been working on infrastructure for
> > user-mode PCI and other drivers. The first step is to be able to
> > handle interrupts from user space. Subsequent patches add
> > inf
On Fri, 11 Mar 2005 14:36:10 +1100, Peter Chubb
<[EMAIL PROTECTED]> wrote:
>
> As many of you will be aware, we've been working on infrastructure for
> user-mode PCI and other drivers. The first step is to be able to
> handle interrupts from user space. Subsequent patches add
> infrastructure for
On Gwe, 2005-03-11 at 03:36, Peter Chubb wrote:
> +static irqreturn_t irq_proc_irq_handler(int irq, void *vidp, struct pt_regs
> *regs)
> +{
> + struct irq_proc *idp = (struct irq_proc *)vidp;
> +
> + BUG_ON(idp->irq != irq);
> + disable_irq_nosync(irq);
> + atomic_inc(&idp->count
We have some customers doing high performance raw I/O from various PCI &
VME cards. They can already mmap() and do DMA from user space to the cards.
Allowing them to do interrupt processing in user space allows them to keep
everything in one tight package. The ULI web site talks about this a
On Fri, Mar 11, 2005 at 07:50:32AM -0600, Michael Raymond wrote:
> I have many users asking for something like this.
Why would a "user" care about this?
Now hardware companies that want to write closed drivers is another
thing :)
thanks,
greg k-h
-
To unsubscribe from this list: send the li
I have many users asking for something like this. Peter's approach is
simple and it appears to solve the problem for many situations.
With that in mind though, for a more complicated but higher performing
approach please take a look at the User Level Interrupt (ULI) project at
http://oss.s
Hi!
> As many of you will be aware, we've been working on infrastructure for
> user-mode PCI and other drivers. The first step is to be able to
> handle interrupts from user space. Subsequent patches add
> infrastructure for setting up DMA for PCI devices.
>
> The user-level interrupt code doesn
As many of you will be aware, we've been working on infrastructure for
user-mode PCI and other drivers. The first step is to be able to
handle interrupts from user space. Subsequent patches add
infrastructure for setting up DMA for PCI devices.
The user-level interrupt code doesn't depend on the
29 matches
Mail list logo