From owner-freebsd-smp Wed Aug 27 15:45:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA15261 for smp-outgoing; Wed, 27 Aug 1997 15:45:42 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA15249 for ; Wed, 27 Aug 1997 15:45:38 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id QAA00398; Wed, 27 Aug 1997 16:44:38 -0600 (MDT) Message-Id: <199708272244.QAA00398@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Terry Lambert cc: petrilli@amber.org, mestery@winternet.com, peters@gil.com.au, smp@FreeBSD.ORG Subject: Re: A how does it work question. In-reply-to: Your message of "Wed, 27 Aug 1997 14:59:04 PDT." <199708272159.OAA00591@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Aug 1997 16:44:38 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > > thats already planned. sio.c and cy.c are already MP-safe from the kernel's > > point of view. The problem is that they are not 'concurrancy-safe', ie > > they never expected to be run concurrently by more than 1 CPU. This > > sort of problem is not so well demonstrated with an example driver, as the > > specific issues will vary from driver to driver. > > I don't think I understand the distinction. If by "the are already > MP safe" you mean "because of the lock", that's not a flaggable > attribute. no, I mean they are MP-safe because I went thru them and added simple-locks around all the regions that are shared by both the ISR and the top half of the kernel. The outer lock in the FAST_INTR() macro is strictly to keep the ISR from being run concurrently, eg CPU0 for an INT on tty0 and CPU1 for an INT on tty1. There are global variables in sio.c that would fail if used concurrantly. --- > The flag I'm talking about is a "this driver may be reentered" flag; > are you saying it's possible to reenter it on the same CPU, but not > on a different CPU? That' might be one issue, but I don't think > that would qualify for the MPSAFE flag... no, there should be no distinction as to CPU, but you obviously can't reenter a fast interrupt from the same CPU, as fast ISRs run to completion, ie they can't be interrupted by themselves. But they could interrupt another CPU which would then attempt to enter the same ISR without the OUTER lock in place to prevent it. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD