From owner-freebsd-arch  Sun Sep 24 20:39:31 2000
Delivered-To: freebsd-arch@freebsd.org
Received: from feral.com (feral.com [192.67.166.1])
	by hub.freebsd.org (Postfix) with ESMTP
	id 61DF437B424; Sun, 24 Sep 2000 20:39:28 -0700 (PDT)
Received: from bird (bird.feral.com [192.67.166.155])
	by feral.com (8.9.3/8.9.3) with ESMTP id UAA01491;
	Sun, 24 Sep 2000 20:38:56 -0700
Date: Sun, 24 Sep 2000 20:38:56 -0700 (PDT)
From: Matthew Jacob <mjacob@feral.com>
Reply-To: mjacob@feral.com
To: Terry Lambert <tlambert@primenet.com>
Cc: Brian Somers <brian@Awfulhak.org>,
	Greg Lehey <grog@wantadilla.lemis.com>, Chuck Paterson <cp@bsdi.com>,
	Archie Cobbs <archie@whistle.com>,
	Joerg Micheel <joerg@cs.waikato.ac.nz>,
	Frank Mayhar <frank@exit.com>, John Baldwin <jhb@pike.osd.bsdi.com>,
	Mark Murray <markm@FreeBSD.ORG>, FreeBSD-arch@FreeBSD.ORG
Subject: Re: Mutexes and semaphores (was: cvs commit: src/sys/conf files
In-Reply-To: <200009250330.UAA05163@usr05.primenet.com>
Message-ID: <Pine.GSO.4.21.0009242036250.506-100000@bird.feral.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


> 
> This is easy: mark them non-reentrant.  You can either acquire a
> mutex on descent into them and release it on exit/sleep, or (and
> this is better), have a per-module mutex that's acquired on the
> descent/wakeup and released on the ascent, if the flag is present.
> This will let the modules be corrected on a per FS and per CAM
> driver basis, while maintaining legacy compatability.  We do not
> need another ethnic clensing of the drivers, such as what we went
> through when CAM went in, or when the X.25 and ISODE stuff was
> murdered.

Hmm, but I sure don't want the pain of the 'unsafe_driver' mutex that Sun went
thru. Still- your point has a lot of maerit.

> 
> 
> > You're missing the point. If you're on Solaris, you are making a mistake in
> > your coding if you're recursing. If you're on FreeBSD, then too many things
> > have still to be redesigned to make that claim.
> 
> I think he understands that, I just think he's unwilling to live
> with a kludge, which will have no incentive to be de-kludged, as
> it wouldn't actually not work.

Whatever... :-)

> 
> It's much better to be able to _know_ what code is OK and what
> code isn't, instead of pretending that it's all OK, when it's not.

Aw, that's not what I was getting at.

I think getting the current set going should be allowed to proceed as is. If
there is a roadmap for strengthening the semantics, great. Just don't make the
bar too high at first.

-matt




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message