Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 Feb 1997 10:58:05 -0800 (PST)
From:      "William R. Somsky" <somsky@dirac.phys.washington.edu>
To:        hackers@freefall.freebsd.org
Subject:   Re: Java binary support in FreeBSD ...
Message-ID:  <199702281858.KAA08836@dirac.phys.washington.edu>
In-Reply-To: <199702281546.HAA01905@freefall.freebsd.org> from "owner-hackers-digest@freefall.freebsd.org" at Feb 28, 97 07:46:51 am

next in thread | previous in thread | raw e-mail | index | archive | help
> > Remember - users don't want to know half the time how things work. They
> > just want it to. :) If a user sees in a blurb that FreeBSD supports
> > executing java "binaries" when you add the jdk package/port, they'll say
> > "wow!".
> > 
> > Just another crazy idea.
> 
> Well, go do it and then come back with your proof-of-concept for us to
> comment on.  Anything else is just blue-sky dreaming, and we've got
> more than enough of that to last us through the remainder of this
> century. :-)

Hmm...  Interesting...  Well, just to toss a little more sky into the
pot, how about something like this: :-)

Now, I don't claim to be a kernel wizard (a kernel wizard is lower than
a general wizard, but above a major wizard or a captain wizard :-) --
sorry, I digress...), but my understanding of what a general Unix
or Unixoid kernel does when it's asked to execute a file is that it
does something along these lines:

1) it looks to see if it's a native binary executable file.  If it is,
   it loads and runs it.

1b) ??? Hmm... what about compatibility modes and such ??? I assume it
    recognizes "compatibility-mode" executables and then DTRT to
    execute them.  (Is something like this going on for FreeBSD's
    elf compatibility?)

2) If it wasn't a binary executable file, it assumes it's a script file
   of some sort, and reads the first line looking for a "shebang" (#!)
   comment to say which interperter to use to run the script.  If it
   finds one, it starts the specified interpreter w/ the script file
   as it's input.

2b) If there wasn't a shebang line, assume it's a Bourne shell script
    and start up "sh" with the file as its input.

If we're going to get into things like being able to execute java files
"directly", ie, having the kernel recognize that it is a java file and
automatically invoking the appropriate java interpreter code, "we" (by
which I mean whoever writes this thing), we will need to have it hooked
in in the 1b) area above.  But if we're going to add a bit to recognize
java code and automatically invoke the appropriate interpreter, shouldn't
we consider that we may eventually want something similar for some other
file type?  Shouldn't we make it a bit more general?

Now, I don't know of all the details, about when various file sytems
become available during the boot process, etc.  But for a very rough
first cut, consider something sort of like this as a strawman that
can be kicked about, disected and probed for any useful bits:

Suppose that at some point during the boot process (or after boot
as part of a loadable kernel module?), the kernel reads and loads
into a table in memory a file /etc/interpreters, which contains
magic-number/interpreter pairs.  Then we add to the above
kernel-execution process a 1c) the kernel compares the file with
the magic-numbers in the magic-number/interpreter table to see
if it is a recognized interpretable file type.  If a match is
found, it invokes the matching interpreter and feeds the file
to the interpreter.  Something like this would give us the
ability to run java files directly, and also any other magic
tagged files that one deems useful in the future.  (Hmm...
maybe this is starting down that slippery slope of identifying
all kinds of different file types with their appropriate
application uses to run/read/handle them ala MacOS or Windows.
YUCK!  Well, what I'm suggesting here would only work for
files marked as executable, and would hopefully be limited to
some small select set.)

Now, the table will have to be loaded at/near boot time, or
when the kernel is poked by some external event/signal/etc,
'cause we definitely do _not_ want the kernel to have to 
read this /etc/interpreters file (or even look to see if
it has changed) each time it tries to execute a file that
isn't a native binary.

Well, anyway, there's my $0.02 on the subject.  Or maybe it's
only worth $0.00000002.  (Or maybe even -$0.02?)  But if anyone's
going to look into this, feel free to take these ideas and kick
them about and see if there is anything of worth in them that
might be useful.
________________________________________________________________________
Dr. William R. Somsky			      somsky@phys.washington.edu
Department of Physics, Box 351560		 B432 Physics-Astro Bldg
Univ. of Washington, Seattle WA 98195-1560		    206/616-2954



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702281858.KAA08836>