From owner-freebsd-hackers Tue Dec 16 16:14:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA14209 for hackers-outgoing; Tue, 16 Dec 1997 16:14:52 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA14201 for ; Tue, 16 Dec 1997 16:14:45 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id KAA00363; Wed, 17 Dec 1997 10:37:59 +1030 (CST) Message-Id: <199712170007.KAA00363@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: ada@bsd.org cc: hackers@FreeBSD.ORG Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port In-reply-to: Your message of "Tue, 16 Dec 1997 19:39:58 +1100." <199712160839.TAA05709@noether.blah.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Dec 1997 10:37:58 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > There is a fundamental problem between this and devfs: Nope. 8) > if devfs waits for the driver to create device nodes, and the driver waits > until its device entry is touched before it's loaded, how does the > process begin? The probe/attach code is in a separate section in the driver module. It's loaded and run based on the bus' probing policy (eg. PCI & PnP load/run on an ID match, ISA loads and probes based on config data), and then discarded. This creates a lazy binding between the device nodes and the module object, which is resolved (the body of the module object is loaded) on first open. The kernel should probably keep the module open to prevent it being deleted/unmounted, and the probe/attach will almost certainly leave data for each instance attached lying around. This is consistent with the conceptual difference between "is it there" (probe/attach) and "I want to use it" (open). mike