From owner-freebsd-hackers Fri Jul 28 14:15:14 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id OAA04983 for hackers-outgoing; Fri, 28 Jul 1995 14:15:14 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id OAA04956 for ; Fri, 28 Jul 1995 14:14:55 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id OAA02492; Fri, 28 Jul 1995 14:15:07 -0700 From: "Rodney W. Grimes" Message-Id: <199507282115.OAA02492@gndrsh.aac.dev.com> Subject: Re: your mail To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 28 Jul 1995 14:15:07 -0700 (PDT) Cc: witr@rwwa.com, hackers@freebsd.org In-Reply-To: <8624.806962590@time.cdrom.com> from "Jordan K. Hubbard" at Jul 28, 95 01:16:30 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1728 Sender: hackers-owner@freebsd.org Precedence: bulk > > > > Oh great. One of UNIX's worst abortions, taken to extremes (can you > > > say "ioctl() is a bogus ``API'' for controlling behavior?" I thought > > > so).. > > > > You are mistaken. Everthing is *not* an ioctl. It instead resembles > > something like the proc filesystem. Do you think *that* is an > > abortion? > > You misunderstood me. I was raising the issue of ioctl() as one > argument (there are more) about how mapping all your devices and files > through a filesystem model was WRONG. And yes, I think the /proc > filesystem is an abortion too. Can you tell me what you thing of Apollo Aegis (aka Domain/OS) typed file objects with type managers? Would you consider that an elegant solution to the ``abortion'' we call a file system based design? I ask because I happen to know you have worked with Apollos in the past and I happen to still do that (infact I own a pair of old crusty 68040/32MB/760MB DN5500's) and have found nothing I like more than the design of that file system for doing nifty netto stuff with (most of the 4.4 file systems could easily be implemented in a weeks time by writting type managers that behavied like them.) Infact this system behavies very much like the vfs ficus stacking stuff, and has for over 10 years, you can add ``stacks'' to it on the fly without ever even looking at kernel code :-) The very first implementation of NFS on apollo was a file type manager, so you can do some mighty powerful things with it. NFS was later pushed into the kernel, but the code was not changed drastically until SR10.3. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD