Geoffrey Plitt wrote:
Dan,
Yes, I can take a stab at converting the test framework to be
linux-runable. At first glance, it appears that the test framework
itself only depends on screen; I can just replace this with some stdio
calls.
Yup, that definitely seems to be the case. Whether intentionally or not,
it appears I've avoided using any of Torsion's own data structure types
in the test framework itself.
It would be nice if types to be tested (like array) could be
used as-is, without referencing to virtmem/physmem, and just used
whatever "new" operator they were linked with - is this feasible? It
doesn't look so.
Well, given that the array type distinguishes between virtual and
physical memory, you're right that just switching directly to a "new"
operator within the array class isn't too feasible. However, it would
definitely be possible to write a "stub" virtual memory allocator and
another stub physical memory allocator. These stubs would implement the
same interface as the real Torsion allocators, but their implementation
would simply wrap the Linux "new" operator. This way, the type being
tested (array) wouldn't need to change at all and could still support
different types of allocation.
For instance, you could add a test/stub/virtmem.h file that's #included
only when compiling unit tests. It might start out like this:
class Virtual_memory;
extern Virtual_memory* virtual_mem;
class Virtual_memory {
public:
void*
alloc(Size request_size) {
return (void*)(new char[request_size]);
}
... and so on
};
If you wanted to get really fancy, in each stub function implementation,
you could record that that particular function was called with the given
arguments. E.g., within the stub alloc() implementation, you could
append to a member list of STL pairs called "invoked_functions" or
something. Each pair could be (called_function_name, arguments_list).
With this sort of function invocation recording, you could assert very
easily that the class being tested (array) is calling the proper
functions on any stub objects that it utilizes.
If you would like any help with any areas of this unit test coding,
please let me know.
The x86 specificty is out of my area of expertise. The more
higher-level the task, the more likely I am to get involved. In fact,
the more I think about it, the more I am getting convinved that
installing a virtual machine (JVM or Mono) on top of the system will
attract a lot of quality contributors, which will really speed up the
rate of development. I think this will lead to a lot of publicty about
torsion, and more widespread adoption.
I agree that a high-level language on top of the system would be very
beneficial, although I'm not sold on the idea of a virtual machine. I'm
continuing work on the lower level stuff currently. Specifically, I've
been working on making tasks themselves persistent. But once that's
hammered out and working, I will be fairly content with the state of the
lower level persistence layer, and I would be freed up to work on fun
stuff like adding a high-level language (or helping you do so).
It seems like the easiest way to get this going is to get the source
of dietlibc and try to get as much of it as possible working and
included on the IMG. I'd like to help out with this. Are there any
special things I have to keep in mind (like exceeding the maximum size
of a floppy image or something) or is all of that handled
automatically? it looks like the code behind "make img" handles that
well.
If the kernel does exceed the size of a floppy with dietlibc added, then
that will be problematic. At some point I'm going to get around to
writing an ATA driver for proper harddisk support, which would obviate
the 1.44 MB limit.
Geoff
Dan
http://torsion.org
_______________________________________________
Torsion-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/torsion-dev