Date: Fri, 07 Mar 1997 10:12:11 +0000 From: James Mansion <james@wgold.demon.co.uk> To: hackers@freefall.freebsd.org Subject: Re: java support under FreeBSD. Message-ID: <331FE9FB.442A@wgold.demon.co.uk> References: <199703070310.TAA03817@squirrel.tgsoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <james@wgold.demon.co.uk> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?331FE9FB.442A>