From owner-freebsd-arch Wed Apr 11 15: 5:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id F34BB37B422; Wed, 11 Apr 2001 15:05:31 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3BM5GG10418; Wed, 11 Apr 2001 15:05:16 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200104112140.RAA14852@aura.research.bell-labs.com> Date: Wed, 11 Apr 2001 15:04:46 -0700 (PDT) From: John Baldwin To: Jeff Fellin Subject: RE: Making a driver SMP-safe Cc: freebsd-smp@FreeBSD.org, freebsd-arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 11-Apr-01 Jeff Fellin wrote: > > I'm not sure this belongs here or in bsd-smp, so I'm dual posting it. > > I have a question on what the actual interfaces, and if there are > any guidelines on how to convert a device driver that runs in a > UniProcessor environement to one that can run on concurrent CPU's > in a MultiProcessor environment. > > Many of the archives talk about mutexes in general, but I haven't > seen a concise description of how a driver needs to deal with SMP > issues. I have written several SMP drivers using the POSIX and other > SMP mutex schemes, so I need to know the API's. > > > I have built my driver on an SMP kernel (STABLE) and it works, > at least to funky lock panics. So, I assume something was done to > prevent concurrent access to my driver in STABLE. I would like to > know what was done to protect the driver from executing concurrently. In stable there is a giant spin lock around the entire kernel, which protects your driver. In -current it's a bit different, but at this point in time it all looks the same to the drivers as there is a Giant mutex that protects 99% of the kernel still. Later on when Giant is split up driver's will start needing to use locks to protect their data as well as to access shared data. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message