Hi, Sorry for the broken header in my first sending attempt... -jm -- ==== John Morrison ==== MaK Technologies Inc. ==== 185 Alewife Brook Parkway, Cambridge, MA 02138 ==== http://www.mak.com/welcome.html ==== vox:617-876-8085 x115 ==== fax:617-876-9208 ==== [EMAIL PROTECTED]
Hi All; Sorry for the wide distribution, but I am interested in hearing your thoughts on the following, JOS-wide, and (unfortunately) related issues... Issue #1: Just bought the "Inside JavaOS" book. Haven't had time to read the whole thing (you know how it is). JavaOS has a quite different (and much more comprehensive) approach to memory classes than any of the ones I wrote about in my recent message to the kernel list (those of you who aren't on the kernel list can check the archives if you're really interested, but I really need your inputs on Issue #2...) Seems they have opaque (to Java, anyways) address32 and address64 classes. They also have "address range" classes, DMA address space classes, and even (seems to me) I/O space classes (as a 16-bit address space). I haven't exactly figured out and/or read far enough to know if/how they handle the *contents* of addresses as unsigned quantities, although I'm sure they can handle it also via opaque classes. Finally, they even seem to have an approach to handling physical<->virtual mapping machinery. So, I guess this comes down to either of two options (please excuse the hyperbole): (1) inventing our own, unique, simplistic, must-be-upgraded-later approach, which will be expedient in the short term, but will never be able to use JavaOS drivers/software, and will be much harder for us to get consensus upon (e.g., agreeing upon driver, system, OS, and "kernel" APIs), or (2) implementing something as close as is humanly possible to the JavaOS API(s), which will be more work in the short term, but maybe less in the long term, and which will obviate the consensus-building group-grope problem we currently have, which makes it much harder to get anything done that involves more than one person... Basically, option (1) is the "let's re-invent the wheel" approach, and (2) is the time-honored, Open Source "chase the tail-lights" approach. As much as I like designing my own APIs (of course, they would be far superior to and more aesthetically pleasing than the JavaOS ones -- *N-O-T*), I'm kind of leaning towards option (2). I mean, hell, we're not redesigning the Java language, the bytecodes, or the java.* classes, so... Issue #2: Are there any legal ramifications of cloning the JavaOS APIs? Is anybody in a position to find out? If there are issues, I'd sure like to know about them right now so that we can do option (1) instead... -jm -- ==== John Morrison ==== MaK Technologies Inc. ==== 185 Alewife Brook Parkway, Cambridge, MA 02138 ==== http://www.mak.com/welcome.html ==== vox:617-876-8085 x115 ==== fax:617-876-9208 ==== [EMAIL PROTECTED]
