From owner-freebsd-hackers Tue Dec 16 00:40:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA07488 for hackers-outgoing; Tue, 16 Dec 1997 00:40:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from noether.blah.org (slmel12p25.ozemail.com.au [203.108.200.113]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA07463 for ; Tue, 16 Dec 1997 00:40:22 -0800 (PST) (envelope-from ada@not-enough.bandwidth.org) Received: (from ada@localhost) by noether.blah.org (8.8.7/8.8.8) id TAA05709 for hackers@freebsd.org; Tue, 16 Dec 1997 19:39:58 +1100 (EST) From: Ada Message-Id: <199712160839.TAA05709@noether.blah.org> Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port In-Reply-To: <199712152018.MAA08626@hub.freebsd.org> from "owner-hackers-digest@freebsd.org" at "Dec 15, 97 12:18:16 pm" To: hackers@freebsd.org Date: Tue, 16 Dec 1997 19:39:58 +1100 (EST) Reply-To: ada@bsd.org X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > From: Jonathan Mini > Date: Sun, 14 Dec 1997 23:32:06 -0800 > Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port > Although it seems rediculous, I ask a different question : "how long until > FreeBSD has a 256k kernel?" I'd like to see a system come into implementation > where all modules can become dynamic, including things such as the UFS and inet > modules, which currently are basically manditory. (the astute reader would > realise that a dynamic module system that did this would require a built-in > dependancy system, but that's another issue altogether) > 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? Ada. -- `Albert, stop telling God what to do.' -- Niels Bohr