From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 21 Jun 2001 11:21:03 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 21 Jun 2001 11:20:53 -0400 Received: from cpe126.netz6.cablesurf.de ([195.206.156.126]:19075 "EHLO idun.neukum.org") by vger.kernel.org with ESMTP id ; Thu, 21 Jun 2001 11:20:48 -0400 Content-Type: text/plain; charset=US-ASCII From: Oliver Neukum To: "Dmitry A. Fedorov" Subject: Re: Is it useful to support user level drivers Date: Thu, 21 Jun 2001 17:19:06 +0200 X-Mailer: KMail [version 1.2] Cc: Balbir Singh , linux-kernel@vger.kernel.org In-Reply-To: In-Reply-To: MIME-Version: 1.0 Message-Id: <01062117190601.02209@idun> Content-Transfer-Encoding: 7BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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