> It is possible, isn't it? We can write C/C++ programs to test/demonstrate
> kernel functions. At the point where jJOS invokes decaf, jJOS could invoke
> a power-on self-test, a diagnostic program, or some other
> test/demonstration program written in C/C++.
The kernel right now is cleanly (sort of) divided between the
ASM, C, and C++ sections. The C++ sections could be unit tested by class,
but almost all of the ASM can't be tested without running it. Someone
who's sufficiently adventerous might be able to hack kdb or VMware to help
out here, but I'm certainly note one of them :) The C section is the
garbage collector, whic is One Of Those Things I Would Someday Like To Try
My Hand At. I'm not really sure what the proper testing procedure for a
garbage collector (esp. on written in C) might be, but if you're curios,
ask George Marrows, who wrote it.
> Where and when should we implement memory management? In the kernel? Or, in
> decaf? Should we do it now, when there is no swap file? Or later?
No, definitely not in decaf. The memory management is going to be
intimately tied with the virtual memory system and the garbage collector,
so they'll need to be looked at together. (For instance, it may be
worthwhile to garbage-collect a page before swapping it out, and so on; do
we prefer to garbage collect before swapping when we run out of RAM? How
does the pager's LRU list interact with the possibility of generational
GC? Etc.)
> We should implement memory management in the kernel. The host build of the
> kernel simply uses the memory management of a foreign operating system. The
> i386 build of the kernel must implement memory management independently
> from any other operating system.
Since we're currently running a monolithic system, much less a
monolithic kernel, I have to agree with you here. On the other hand,
Linux seems to be doing just fine with a user-space swapper, etc -- and
Mach with its microkernel architecture. Whatever we en up doing w.r.t. to
memory management should be portable with the minimum of effort to
whatever kernel/system design we end up `finalizing' on.
-_Quinn
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
