From owner-freebsd-hackers Tue Dec 16 11:14:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA20307 for hackers-outgoing; Tue, 16 Dec 1997 11:14:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA20286 for ; Tue, 16 Dec 1997 11:14:39 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id MAA21549; Tue, 16 Dec 1997 12:31:14 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpd021524; Tue Dec 16 12:31:09 1997 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id MAA19768; Tue, 16 Dec 1997 12:14:24 -0700 (MST) From: Terry Lambert Message-Id: <199712161914.MAA19768@usr01.primenet.com> Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port To: ada@bsd.org Date: Tue, 16 Dec 1997 19:14:24 +0000 (GMT) Cc: hackers@freebsd.org In-Reply-To: <199712160839.TAA05709@noether.blah.org> from "Ada" at Dec 16, 97 07:39:58 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > This type of dynamic loading of modules can't be implemented correctly until > > we have a method of easily tracking resources dynamically. John-Mark's > > bus/device system does this, and, based on my observations of he current > > codebase, it is obvious (at least to me, YMMV) that this code is greatly > > required. > There is a fundamental problem between this and devfs: > > 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 code is seperate from the code that implements what is being probed for... it lives in a seperate ELF segment in the driver image. Alternately, you load the driver, try the probe, and if it fails, you discard the driver. You can do this on a whole driver without needing initial support for ELF sections seperating the probe code. This presumes that in a post-link static kernel that drivers which may be discarded live in their own sections. This lets the kernel recover the memory used by an unused static device. If you have section tagging (preload,nonswappable) for boot critical and swap path components, then the kernel loader can decide to load only part of the kernel initially. You could then also have the scenario where you have all devices linked into the kernel, and the kernel's disk footprint was much larger than the kernels memory footprint. This is actually a less desirable scenario, however, since it means that it's more difficult to dynamically add things like third party drivers and FS's. I personally have a preference for /libexec and /usr/libexec for boot-path and non-boot-path components for things like file systems. The boot FS must be statically linked for the kernel to be able to find additional components, but after that, what's needed? Basically, a way to hook a new FS into the FS commands (mount/fsck/etc.) and a way to get the code into the kernel on demand. A probe=true is the definition of an "arrival event". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.