From owner-freebsd-hackers@FreeBSD.ORG  Fri Sep 22 01:41:26 2006
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
X-Original-To: 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 74E5F16A47C
	for <freebsd-hackers@freebsd.org>; Fri, 22 Sep 2006 01:41:26 +0000 (UTC)
	(envelope-from jhb@freebsd.org)
Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net
	[66.23.211.162])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 3061D43D55
	for <freebsd-hackers@freebsd.org>; Fri, 22 Sep 2006 01:41:16 +0000 (GMT)
	(envelope-from jhb@freebsd.org)
Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7])
	(authenticated bits=0)
	by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k8M1f7U0009019;
	Thu, 21 Sep 2006 21:41:10 -0400 (EDT) (envelope-from jhb@freebsd.org)
From: John Baldwin <jhb@freebsd.org>
To: "Intron is my alias on the Internet" <mag@intron.ac>
Date: Thu, 21 Sep 2006 21:36:18 -0400
User-Agent: KMail/1.9.1
References: <courier.4512D623.00003440@intron.ac>
In-Reply-To: <courier.4512D623.00003440@intron.ac>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="gb2312"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200609212136.18850.jhb@freebsd.org>
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by
	milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]);
	Thu, 21 Sep 2006 21:41:10 -0400 (EDT)
X-Virus-Scanned: ClamAV 0.88.3/1922/Thu Sep 21 19:05:55 2006 on
	server.baldwin.cx
X-Virus-Status: Clean
X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 
	autolearn=ham version=3.1.3
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx
Cc: freebsd-hackers@freebsd.org
Subject: Re: A Bug in linker_reference_module() ?
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
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: Fri, 22 Sep 2006 01:41:26 -0000

On Thursday 21 September 2006 14:12, Intron is my alias on the Internet wrote:
> Please have a look at the function linker_reference_module() in
> /sys/kern/kern_linker.c of 7.0-CURRENT. If the module is loaded on demand,
> why not increase its reference counter after loading? In my opinion,
> linker_reference_module() behaves differently from linker_load_file().

This is because a new kld loaded via linker_load_module() starts off
with a refcount of 1.  Thus, if you do:

	linker_reference_module(...);
	...
	linker_release_module(...);

Then with the current code the release_module() call drops the reference
count to 0 and the module is unloaded.  This is the desired operation for
reference_module/release_module.  This model is commonly used in the kernel.
For example, when creating a credential, one just does 'crget()' and later
a 'crfree()' to free it instead of doing 'crget(); crhold()' to create one.

-- 
John Baldwin