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
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
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 interrupt
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 performance even with a
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
> "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
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
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
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 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 performance even with a
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-level networking between nodes in a
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 are
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 way malicious or
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 occurred on
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
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
> "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
> "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
>>
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
> "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
> "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
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(>count);
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);
+
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 interrupts from user
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 to handle interrupts
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 anything else.
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
infrastructure for user-mode
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
information to disable
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-level networking between nodes in a
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 too
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 performance even with a
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
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
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
> >
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
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 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
infrastructure
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 space.
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 point
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 to
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(>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
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
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
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't
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
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 line
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 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);
+
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
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
57 matches
Mail list logo
