From owner-freebsd-current Mon Aug 4 09:38:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA09378 for current-outgoing; Mon, 4 Aug 1997 09:38:00 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA09370 for ; Mon, 4 Aug 1997 09:37:57 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA04158; Mon, 4 Aug 1997 09:36:37 -0700 From: Terry Lambert Message-Id: <199708041636.JAA04158@phaeton.artisoft.com> Subject: Re: Some thoughts and ideas, and quirks To: garbanzo@hooked.net (Alex) Date: Mon, 4 Aug 1997 09:36:37 -0700 (MST) Cc: terry@lambert.org, current@FreeBSD.ORG In-Reply-To: from "Alex" at Aug 3, 97 05:03:47 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > That brings me to another thought or 5 ;) . What about an rc.modules? Why not a /kern/modules instead, and use opendir() to iterate them, and demand load them when necessary? I don't see a reason for rc.* based loading if demand-loading works... > Also, some things are lacking, like for instance it appears to me that you > don't need to statically compile ccd or ppp devices. Yeah, devfs is lacking, most because people insist there is a persistance "problem" that can't be solved by putting the default permissions into the device code's static data for whatever device, from which the devfs data is derived. > However the uid > filesystem thing does need to be statically compiled as does ext2, both > typos in the lint, and man pages, etc. No. Those are typos in the uid and ext2 FS code, not typos in LINT or the man pages. Don't confuse bugs with policy. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.