Hi John,
I've updated the CVS today. It compiles well and the TestSuite class starts,
but it seems a to be a bug in the interrupt handling: when I strike a key I see
the message:
notifyOfInterrupts(4): VM corrupted, aborting....
what happens ? What I have forgotten ?
Cheers,
Corrado.
On Mon, 15 Nov 1999, John Morrison wrote:
> Hi;
>
> Well, I got a couple of free minutes, and made some minor changes
> (hope I didn't break anything -- please shriek loudly if I did).
>
> (1) I changed common/decaf/scheduler.cc. There seemed to me to be
> some code that complained if an interrupt happened that there was not
> a java thread waiting on it. I got rid of that clause, because I
> think that is an OK thing -- not an error.
>
> (2) I had been sitting on changes I had made to
> common/nativecode/jbheap.cc, for which I had made an alternative
> malloc/free implementation. I just wanted to get that code into the
> repository. Hopefully, it shouldn't be used (unless you change some
> #defines in the file), and thus it shouldn't break anything. I'll
> probably nuke it the next time I touch that file, but ...
>
> (3) I added a new file, common/bytecode/TestSuite.java. I swept all
> the test* methods away from init.* and into TestSuite.*. Obviously, I
> also thus had the change init.java, and also the Makefile in that
> directory to add the new file.
>
> This change was important because I would like to start implementing
> the "device tree" infrastructure. Basically, the BIOS scans the
> devices in the box at boot time, and is kind enough to leave a record
> of what it found in the "BIOS data area." I would like to scan this
> area from Java (early in the "init" code), and make Java "device tree"
> data structures (as JavaOS does) so that we can load the right drivers
> for the devices we actually have. This is the analog to the /dev/*
> hierarchy in UNIX. Hopefully, after this code has finished running,
> you'll (or the Java code will) be able to easily figure out what
> devices are hanging off the box, and removable and hot-swappable
> devices will be handled via a "notification" mechanism.
>
> On a directly related note, there was recently a big discussion on the
> Linux kernel lists (I don't monitor these lists, but the Linux weekly
> news had a synopsis of the discussion) about how removable media, and
> large numbers of networked devices raised hell with the old UNIX-style
> static device hierarchy. I think they were headed in this general
> direction (technically speaking).
>
> As usual, problems to me...
>
> -jm
>
> --
> ==== John Morrison
> ==== MaK Technologies Inc.
> ==== 185 Alewife Brook Parkway, Cambridge, MA 02138
> ==== http://www.mak.com/
> ==== vox:617-876-8085 x115
> ==== fax:617-876-9208
> ==== [EMAIL PROTECTED]
>
> _______________________________________________
> Kernel maillist - [EMAIL PROTECTED]
> http://jos.org/mailman/listinfo/kernel
--
======================================================
Eng. Corrado Santoro - PhD Student
Unversity of Catania - Engineering Faculty
Institute of Computer Science and Telecommunications
Viale A. Doria, 6 - 95125 CATANIA (ITALY)
Tel: +39 095 7382365 Fax: +39 095 7382397
EMail: [EMAIL PROTECTED]
Personal Home Page:
http://www.cdc.unict.it/~csanto
ARCA Mobile Agent Framework Home Page:
http://netra.cdc.unict.it/ARCA
======================================================
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
