From owner-freebsd-arch Tue Jul 18 20:55:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-51.dsl.snfc21.pacbell.net [63.202.177.51]) by hub.freebsd.org (Postfix) with ESMTP id DC2BD37B7FE; Tue, 18 Jul 2000 20:55:22 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id VAA21389; Tue, 18 Jul 2000 21:03:59 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200007190403.VAA21389@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Greg Lehey Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process In-reply-to: Your message of "Wed, 19 Jul 2000 13:09:07 +0930." <20000719130907.H12072@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jul 2000 21:03:59 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The INTR_TYPE_TTY interrupts, except fast ones, are masked as a unit. > > Likewise with the INTR_TYPE_NET, etc. The intent here is to provide > > assistance in serialization of access to crititical structures. When > > you do a splnet, all the net devices who have an interrupt have their > > interrupt blocked. > > Right, that's the current way things are done. This will change too, > to be replaced by relative scheduling priorities. That's the more > interesting question: how should they relate to each other? As a general rule, they shouldn't. Don't get carried away with something relatively trivial like which interrupts should have "more" scheduling priority - just get them being scheduled at all for now. 8) > That's what I thought. Does anybody else see a reason to convert fast > interrupts into threads? No. Or more specifically, we need a mechanism for "classic-style" low-latency interrupt handlers. These will typically be coupled with a software-interrupt thread, more or less as they are now. > I can't see anything inherent in the treatment of fast interrupts > which says they can't be shared. I'll take another look at the code; > maybe we can get rid of this restriction. Sharing a 'fast' interrupt completely defeats the point of making it 'fast'. You should not be able to register a 'fast' handler on any source with anything else attached, nor anything else on a source that has a 'fast' handler already registered. Yes, this does impose some configuration constraints on the system, but there are few viable alternatives. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message