From owner-freebsd-hackers Tue Aug 12 09:35:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA02598 for hackers-outgoing; Tue, 12 Aug 1997 09:35:04 -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 JAA02576 for ; Tue, 12 Aug 1997 09:34:59 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA25517; Tue, 12 Aug 1997 09:29:31 -0700 From: Terry Lambert Message-Id: <199708121629.JAA25517@phaeton.artisoft.com> Subject: Re: your mail To: jamil@counterintelligence.ml.org (Jamil J. Weatherbee) Date: Tue, 12 Aug 1997 09:29:30 -0700 (MST) Cc: Shimon@i-Connect.Net, FreeBSD-Hackers@FreeBSD.ORG In-Reply-To: from "Jamil J. Weatherbee" at Aug 12, 97 02:10:51 am 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > This is definetly not something that would become part of a production > kernel -- seems that it is far to specific, the bsd kernel is not a > database engine, that's what mmap is for. Supporting this type of thing without having to actually put it in the kernel to make it work is what LKM's are for. Personally, I think there is a lot of room for purpose-built FS's and FS layers. I've been looking back into a generic block store, recently: a flat numeric namespace, on top of which other namespaces are implemented. It's one level of abstraction up from a device interface, and would provide a consistent, cross-platform bottom-end definition: the FS layers could be divorced from FreeBSD or OpenBSD or NetBSD or BSDI or SVR4 or Windows95 VM semantics. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.