Hi Guys; Sorry for the wide distribution, but I do not know which of these aliases go to which classpath developer... Please find attached an email message from Todd Miller, the chief/key "decaf" JVM developer for the JOS "Java OS" project (www.jos.org). At his request, I am forwarding this message to you all for a sanity-check of his impressions. Please note: (1) When Todd refers to the "i386" build, it's a bare-iron, no-host-OS build of the JVM. Java right down to the silicon. (When he refers to a "host" build, it's a more debugging-friendly vanilla Linux ELF program -- it's no fun debugging a JVM without a debugger.) (2) For your information, the JVM is pretty complete, and we are currently writing Java-language device drivers for the keyboard, VGA display (etc.) for the i386 build (i.e., we are well past the "wouldn't it be nice to have a Java OS" stage). (3) We'd like to do everything possible in Java, and as little as possible in "native" code (think of native code as microcode). In a perfect world, classpath would not require any native code (we realize we do not live in even a reasonably nice world, let alone a perfect one -- however, our desire to minimize native code is not unreasonable given our low-memory constraints). Building a dynamic native-code/microcode linker to handle ELF format .o files is something I personally would like to avoid (I am more or less responsible for the low-level systems programming). (4) Finally, also FYI, we currently believe we should chase the recently-defunct JavaOS APIs. Any help you give us would be greatly appreciated. Very Truly Yours, -jm -- ==== John Morrison ==== MaK Technologies, Inc. ==== Chief Technology Officer ==== 185 Alewife Brook Pkwy, Cambridge, MA 02138 ==== [EMAIL PROTECTED] ==== http://www.mak.com/ ==== vox:617-876-8085 x115 ==== fax:617-876-9208
I've been playing with classpath for the past few days, so I'd figure I'd check in with my understanding so far. (A) We'll need to add JNI if we want to use classpath's native code. (B) Some amount of that native code will have libc stuff in it. While this shouldn't be a terrible problem for the host build (anyone actually /know/?) it's a disaster for the i386 build. It looks like they put all the native code in classpath/native/*, which means we should be able to point the Makefiles at something like classpath/i386/* and everything will be happy. (C) It looks all the jvm-specific bits have been localized to java classes in classpath/vm/*, which can just implement in jjos/common/decaf[/vm]. (D) The anonymous CVS server doesn't seem to have the 'configure' script in it, so get the snapshot if you're interested in working on it. (E) Likewise, the configure script seems to want japhar to be installed (looks for 'japhar-config'); someone should find out what the configure script needs to know from this. (Then implement a --with-jjos option on the config?) (F) Because of (E), I haven't been able to build a classes.zip out of classpath, and see how well it works with jjos/decaf. JM, you've been in contact with the classpath developers; if you could run my suspicions and questions by (one of) them, that would be great. -_Quinn _______________________________________________ Kernel maillist - [EMAIL PROTECTED] http://jos.org/mailman/listinfo/kernel
