From owner-freebsd-current@FreeBSD.ORG  Sun Jun 26 17:54:16 2011
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 9FE6F1065670
	for <freebsd-current@FreeBSD.org>; Sun, 26 Jun 2011 17:54:16 +0000 (UTC)
	(envelope-from imp@bsdimp.com)
Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85])
	by mx1.freebsd.org (Postfix) with ESMTP id 5A1A48FC0A
	for <freebsd-current@FreeBSD.org>; Sun, 26 Jun 2011 17:54:16 +0000 (UTC)
Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63])
	(authenticated bits=0)
	by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5QHqX7w043389
	(version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO);
	Sun, 26 Jun 2011 11:52:34 -0600 (MDT) (envelope-from imp@bsdimp.com)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warner Losh <imp@bsdimp.com>
In-Reply-To: <BANLkTikdww3jDM_ennzjFHKmKU0WrDBDHA@mail.gmail.com>
Date: Sun, 26 Jun 2011 11:51:51 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <B9BDB3DC-7F3C-4D4E-AEA6-3AD36409D2CD@bsdimp.com>
References: <201106242342.47194.hselasky@c2i.net>
	<ACCD2B48-1E78-42B6-883E-542FDFD567F6@bsdimp.com>
	<201106251907.02052.hselasky@c2i.net>
	<201106260738.21847.hselasky@c2i.net>
	<BANLkTikdww3jDM_ennzjFHKmKU0WrDBDHA@mail.gmail.com>
To: Robert Millan <rmh@debian.org>
X-Mailer: Apple Mail (2.1084)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1
	(harmony.bsdimp.com [10.0.0.6]);
	Sun, 26 Jun 2011 11:52:35 -0600 (MDT)
Cc: Jeremy Messenger <mezz.freebsd@gmail.com>, freebsd-current@FreeBSD.org,
	Hans Petter Selasky <hselasky@c2i.net>
Subject: Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load
	of USB kernel modules]
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jun 2011 17:54:16 -0000


On Jun 26, 2011, at 4:33 AM, Robert Millan wrote:

> 2011/6/26 Hans Petter Selasky <hselasky@c2i.net>:
>> Hi,
>>=20
>> I see that a lot of PCI device drivers use code to check their ID's.
>>=20
>> [...]
>=20
> I seem to recall devd doesn't process PCI because it is event-driven =
and
> there are no "events" associated with PCI cards.

That's totally false.

> Perhaps it could be modified to scan for PCI cards via libpci on =
initialization
> and generate "fake" events for them?

Since your premise is false, this solution also is false.

Devices are handled in a completely uniform manner in the system.  When =
they attach, an attach even is generated.  When they detach, a detach =
event is generated.  When there is no driver attached after the =
probe/attach sequence, a NOMATCH event is generated.  Events are queued =
up during the early boot process until devd can run.  They are then =
processed in order.  Devices that haven't had a driver attach to them =
would be processed when devd had a chance to start.

Warner