From owner-freebsd-hackers Thu Mar 6 09:55:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA01184 for hackers-outgoing; Thu, 6 Mar 1997 09:55:44 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA01179 for ; Thu, 6 Mar 1997 09:55:42 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA13693; Thu, 6 Mar 1997 10:49:34 -0700 From: Terry Lambert Message-Id: <199703061749.KAA13693@phaeton.artisoft.com> Subject: Re: java support under FreeBSD. To: james@wgold.demon.co.uk (James Mansion) Date: Thu, 6 Mar 1997 10:49:34 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <331EA126.412D@wgold.demon.co.uk> from "James Mansion" at Mar 6, 97 10:49:10 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 > Would it be possible to write a layered filter file system > and mount it onto some part or parts of the main system so that, > if I try to stat or open 'foo', and 'foo' does not exist but > 'foo.class' doesn't, then I see a read-only executable file called > 'foo', maybe one that has contents '#!/somewhere/java foo.class' > or therabouts? The problem is with the iteration of directory contents; this is why we were talking about globbing in the kernel. You want to find 'foo' before 'foo.class' even if 'foo' is later in the path than a 'foo.class'. Besides which, even if it were a good idea, it can't be (easily, at any rate) implemented. Currently, I don't believe that mounting a NULLFS layer will work properly; system calls are considered more equal than other VFS interface consumers -- like the NFS server, or a stacking mount. This is the fames "layering problems". One of the biggest areas of fault is the VOP_LOCK(); the other is VOP_READDIR(); I believe that the NULLFS mount still fails following Lite2 integration for reasons of VOP_LOCK/vclean lock flagging (it's calldown instead of veto, so a "transparent" layer would have to lock against itself, which fails). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.