From owner-freebsd-ports@FreeBSD.ORG  Thu Nov 23 21:23:02 2006
Return-Path: <owner-freebsd-ports@FreeBSD.ORG>
X-Original-To: freebsd-ports@freebsd.org
Delivered-To: freebsd-ports@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 89FB416A407
	for <freebsd-ports@freebsd.org>; Thu, 23 Nov 2006 21:23:02 +0000 (UTC)
	(envelope-from bakul@bitblocks.com)
Received: from mail.bitblocks.com (bitblocks.com [209.204.185.216])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 3F6BB43D55
	for <freebsd-ports@freebsd.org>; Thu, 23 Nov 2006 21:22:25 +0000 (GMT)
	(envelope-from bakul@bitblocks.com)
Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1])
	by mail.bitblocks.com (Postfix) with ESMTP id C7C445B3E;
	Thu, 23 Nov 2006 13:23:01 -0800 (PST)
To: Kris Kennaway <kris@obsecurity.org>
In-reply-to: Your message of "Thu, 23 Nov 2006 16:15:32 EST."
	<20061123211532.GB83751@xor.obsecurity.org> 
Date: Thu, 23 Nov 2006 13:23:01 -0800
From: Bakul Shah <bakul@bitblocks.com>
Message-Id: <20061123212301.C7C445B3E@mail.bitblocks.com>
Cc: FreeBSD Ports <freebsd-ports@freebsd.org>,
	Anders Troback <freebsd@troback.com>
Subject: Re: Qemu crash... 
X-BeenThere: freebsd-ports@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Porting software to FreeBSD <freebsd-ports.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ports>,
	<mailto:freebsd-ports-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ports>
List-Post: <mailto:freebsd-ports@freebsd.org>
List-Help: <mailto:freebsd-ports-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ports>,
	<mailto:freebsd-ports-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Nov 2006 21:23:02 -0000

> The problem is that kldloading a module if it's already in the kernel
> can cause a panic.  Also if the module becomes stale with respect to
> the running kernel, this approach can cause a lot of confusion.

I thought the following would do the trick:

    kldstat -m aio >/devnull 2>&1 || kldload aio

> Something I'd like to see is
> 
> a) Fixing the kldload "double load" problems

See above.  Works in -current at least.

> b) That optional kernel subsystems register themselves with a sysctl,
> so that userland can easily determine whether a feature is present in
> the running kernel and take appropriate action (warn user, demand
> load, etc) if not.  compat[45]x support is another such case; there's
> no way for a port to tell whether the kernel supports running such
> binaries, and if not then the user will just get an error when they
> try to run it.

Isn't kldstat -v & kldstat -m good enough?