Re: [Torsion-dev] Torsion 0.0.18 released

[Dan Helfman]

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