From owner-freebsd-smp  Thu Dec  5 09:59:22 1996
Return-Path: <owner-smp>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id JAA20843
          for smp-outgoing; Thu, 5 Dec 1996 09:59:22 -0800 (PST)
Received: from cs.utah.edu (cs.utah.edu [128.110.4.21])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA20838
          for <smp@freebsd.org>; Thu, 5 Dec 1996 09:59:17 -0800 (PST)
Received: from fast.cs.utah.edu by cs.utah.edu (8.8.3/utah-2.21-cs)
	id KAA18537; Thu, 5 Dec 1996 10:59:07 -0700 (MST)
Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf)
	id KAA19283; Thu, 5 Dec 1996 10:59:01 -0700
Date: Thu, 5 Dec 1996 10:59:01 -0700
From: vanmaren@fast.cs.utah.edu (Kevin Van Maren)
Message-Id: <199612051759.KAA19283@fast.cs.utah.edu>
To: smp@csn.net, vanmaren@fast.cs.utah.edu
Subject: Re: make locking more generic?
Cc: ccsanady@friley216.res.iastate.edu, peter@spinner.dialix.com,
        smp@freebsd.org
Sender: owner-smp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

My thinking was mainly that the drivers have never been tested
in this environment.

If you have a driver that is used for two devices, and you
allow both to generate interrupts and have the driver executing
on two processors simultaneously, the shared data structures
are not going to be protected.  So the simple fix would be to
put a lock around each driver.  But you will still have
problems with other shared data structures; the same problem
with allowing multiple processes to make kernel calls.

This is all part of the enormous problem of adding fine-grained 
locking to an existing single-threaded kernel.

Kevin