From owner-freebsd-hackers@FreeBSD.ORG  Thu Dec 25 12:58:07 2003
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id E2C8D16A4CE
	for <freebsd-hackers@FreeBSD.ORG>;
	Thu, 25 Dec 2003 12:58:07 -0800 (PST)
Received: from mxsf17.cluster1.charter.net (mxsf17.cluster1.charter.net
	[209.225.28.217])
	by mx1.FreeBSD.org (Postfix) with ESMTP id BCECE43D31
	for <freebsd-hackers@FreeBSD.ORG>;
	Thu, 25 Dec 2003 12:58:06 -0800 (PST)	(envelope-from ups@stups.com)
Received: from stups.com ([209.187.143.11])hBPKum7D030257
	for <freebsd-hackers@FreeBSD.ORG>;
	Thu, 25 Dec 2003 15:56:48 -0500 (EST)	(envelope-from ups@stups.com)
Received: from tree.com (localhost [127.0.0.1])
	by stups.com (8.9.3/8.9.3) with ESMTP id XAA17441
	for <freebsd-hackers@FreeBSD.ORG>; Thu, 25 Dec 2003 23:59:25 -0500
Message-Id: <200312260459.XAA17441@stups.com>
X-Mailer: exmh version 2.0.2
To: freebsd-hackers@FreeBSD.ORG
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 25 Dec 2003 23:59:25 -0500
From: Stephan Uphoff <ups@stups.com>
Subject: (mtx|sx)_init zeroed memory requirement plans?
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Dec 2003 20:58:08 -0000


Currently both mtx_init() and sx_init() make assumptions about the
lock memory passed in.	( KASSERT((lock->lo_flags & LO_INITIALIZED) == 0))

To fulfill this requirement current code that works with dynamically 
allocated memory routinely zeroes the lock memory space before
calling the lock initialization function.
( Or allocates zeroed memory)

Is this (undocumented?) behavior just a temporary debugging aid - or
will it stay around ?

If it is not going away anytime soon I would suggest adding 
MTX_PREPARE and SX_PREPARE macros instead of zeroing the lock memory.

This would make it easier to remove or optimize lock memory preparation
later on.


	Stephan