From owner-freebsd-hackers Fri Mar 7 08:08:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA23336 for hackers-outgoing; Fri, 7 Mar 1997 08:08:03 -0800 (PST) Received: from wgold.demon.co.uk (wgold.demon.co.uk [158.152.96.124]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id IAA23305 for ; Fri, 7 Mar 1997 08:07:58 -0800 (PST) Received: from wgold.demon.co.uk by wgold.demon.co.uk (NTMail 3.02.10) with ESMTP id za001247 for ; Fri, 7 Mar 1997 10:12:12 +0000 Message-ID: <331FE9FB.442A@wgold.demon.co.uk> Date: Fri, 07 Mar 1997 10:12:11 +0000 From: James Mansion Organization: Westongold Ltd X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: hackers@freefall.freebsd.org Subject: Re: java support under FreeBSD. References: <199703070310.TAA03817@squirrel.tgsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Info: Westongold Ltd: +44 1992 620025 www.westongold.com Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hmm. I'm sorry that you considered my suggestion to be 'bloating the kernel'. I thought it was more modular. In particular it is much more optional and visible and controllable. I accept Terry's argument that the implementation is hard. I have to, because I don't have any familiarity with the way thtat the file system code works. Perhaps I naively thought that the kernel already supported overlay file systems like cachefs and ones that allow mounting a write layer over a CDROM and other such stuff that might be available elsewhere (ahem!). I didn't like Terry's assumption that there would be a search order issue though. Suppose I limit the functionality on my suggestion a bit more - the ONLY files that appear in this filesystem are the implied executables that shadow the java class files. Thus, if I mount /mnt/javahack over /etc/local/javastuff and there exists a file /etc/local/javastuff/zippy/foo.class then the hack system will appear to contain /mnt/javahack/zippy/foo. It is entirely up to me where (or whether) I put /mnt/javahack/zippy in my path, and the effect on search order is exactly the same as if /mnt/jazahack/zippy were a real directory containing a real stub executable called foo. So I think Terry's concern over having to force a complete search for 'foo' before trying to fake things with 'foo.class' is misplaced. I'm pretty horified by large-scale hacks to shells or moving globbing or frigging exec routines, which have a very well defined behaviour. mark thompson wrote: > > From: James Mansion > Date: Thu, 06 Mar 1997 10:49:10 +0000 > > I have a suggestion wrt 'foo'class' rather than 'foo'. > > 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? > > James > > aaaarrrgggghhhhh. This is getting worse and worse. Instead of bloating > the kernel, how about about adding it to execvp (or whatever we can get > the shells to agree on). You could even have it driven by a file in > /etc... > > # exec wrapper for the shells... > java % "java %.class -various magic params" > perl % "perl %.pl" > ... > > -mark