From owner-freebsd-hackers Mon Dec 16 17:17:15 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA21966 for hackers-outgoing; Mon, 16 Dec 1996 17:17:15 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id RAA21960 for ; Mon, 16 Dec 1996 17:17:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA04996; Mon, 16 Dec 1996 18:13:37 -0700 From: Terry Lambert Message-Id: <199612170113.SAA04996@phaeton.artisoft.com> Subject: Re: Heidemann Framework integration (Re: Other filesystems under FreeBSD) To: michaelh@cet.co.jp (Michael Hancock) Date: Mon, 16 Dec 1996 18:13:37 -0700 (MST) Cc: terry@lambert.org, koshy@india.hp.com, freebsd-hackers@freefall.freebsd.org In-Reply-To: from "Michael Hancock" at Dec 17, 96 09:58:49 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The main problem areas in the 4.4BSD/FreeBSD implementation of the > > Heidemann framework are: > > > > There are also vops that don't take a vp as a parameter. bwrite and > bstrategy. They should; more likely, blocked I/O should be implemented as a layer above the FS. The devfs code is a very special case if you don't have specfs or allow device nodes on other FS's (you can use symlinks for the same effect). Given that, if there were still a need for it, and it couldn't be represented in the uio struct, or in the name space by virtue of the vp that came back from the open, then VOP_IOCTL on the vp seems right. Anyway... that's part of "and so on...". Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.