Toro kernel

IOAPIC supported!

2012-01-03T16:42:00.000-08:00

Until the latest TORO's source, I was using 8259 controller to catch interrupts, but the problem was all the interrupts were captured by the Boot Strap Processor (or core #0). This is not agree with the dedicate hardware model.

In this way, I have started to use the IOAPIC instance of 8259 when TORO runs in a multicore environment. Thus, I can redirect the IRQ to the core where the hardware was dedicated. This is new a new step toward a real multicore kernel.

Matias E. Vara

www.torokernel.org

Fixed an important bug in emigrate procedure

2011-12-12T09:17:00.000-08:00

That's just a brief post about a recent change in the way that Toro migrates threads.

Previously, when a Thread running in core #0 wanted create a new Thread in core #1, function ThreadCreate allocated the TThread structure, TLS and the Stack then, It migrated the whole TThread structure to the core #1.

The main problem in this mechanism was that all memories block were allocated in parent core. This is a serious infraction in the NUMA model: TThread, TLS and the Stack are not already local memory.

Thus, I rewrote the way that Threads are migrated. When a Thread wants to create a new one remotely, Toro still invokes ThreadCreate BUT it is executed in the remote core. Instance of migrate the TThread structure, now Toro migrates a set of arguments to be passed toward ThreadCreate. When ThreadCreate finishes, the parent thread retrieve the TThreadID value or nil if it fails.

As we can see, while a local thread is made immediately when ThreadCreate is invoked, a remote thread spend two steps of latency: one for migrate the parameters and other for retrieve the result.

Matias E. Vara

www.torokernel.org

Patching GDB 7.3 for QEMU remote kernel debug

2011-08-25T17:58:00.000-07:00

This time I will try to explain how patch GDB 7.3 in order to debug a kernel using QEMU through remote debuging. If we try to debug remotely, we'll find a error message like:

Remote packet too long: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ...

I am not sure about problem but I suppose it's about register size. When the virtual machine jumps from real mode to long/protect mode, the register size changes but GDB doesn't know that. Thus, when GDB receives a bigger packet than it expects, it fails. Therefore, The patch just increments the buffer in those cases.

The first step is to download GDB 7.3 from http://www.gnu.org/s/gdb/download/, I've implemented the patch on 7.3 version but I think it works in oldest too.

Once downloaded and uncompressed, edit the file gdb-7.3/gdb/remote.c and go to 5693 line. That's the process_g_packet procedure. Now, look for and replace the original source with the following lines:

/* Further sanity checks, with knowledge of the architecture. */

//if (buf_len > 2 * rsa->sizeof_g_packet)

// error (_("Remote 'g' packet reply is too long: %s"), rs->buf);

if (buf_len > 2 * rsa->sizeof_g_packet)

{

rsa->sizeof_g_packet = buf_len;

for (i = 0; i < gdbarch_num_regs (gdbarch); i++)

{

if (rsa->regs[i].pnum == -1)

continue;

if (rsa->regs[i].offset >= rsa->sizeof_g_packet)

rsa->regs[i].in_g_packet = 0;

else

rsa->regs[i].in_g_packet = 1;

}

Finally, it just remains to execute:

$ ./configure

$ make

It must be enough to run GDB correctly.

Matias E. Vara

www.torokernel.org

Toro in Microelectronic Conference (UNLP)

2011-08-23T15:03:00.000-07:00

Toro will be shown in the Microelectronic Conference at University of La Plata, Argentina. In the work that I've done I will show the kernel capabilities and a few tests comparing Toro with a general purpose operative system. The conference will be the 8th of September in "Sala A" at 16.20hs.

Matias E. Vara

www.torokernel.org

Toro in Ubuntu 11.04!

2011-07-30T15:50:00.000-07:00

Now It is possible to compile and test TORO easy trough Linux Ubuntu 11.04. Actually, I am moving the whole project to Linux environment. In other way, I have started to use GIT in order to simplify the developed. I have updated the WIKI, giving the instructions to compile and TORO in Ubuntu.

Enjoy!

Matias E. Vara

www.torokernel.org

Toro bootloader

2011-06-24T03:07:00.001-07:00

How can I start it?. The bootloader is a project itself, if you want to write a hobby OS you do not have to start from the bootloader. First, It will take you a lot of time, second, it is too hard to debug so you will become disappointed fast and you wont finish. I think that the important and interested things happens inside the kernel. Anyway, there are a few crazy guys that they want to make one. For that kind of guys, I have just started to write a few documentation about Toro's bootloader in the wiki. I hope that you find it interesting and appreciate the effort done (Yes, I don't like to write documentation but I know that it is too important ;) ).

Matias E. Vara

www.torokernel.org

Memory Protection in a multicore environment

2011-04-17T07:23:00.001-07:00

This post is contained into the final paper of Matias Vara named “Paralelizacion de Algoritmos Numericos con TORO Kernel” to get the degree on Electronic Engeniering from Universidad de La Plata. These theorical documents help to understand the kernel design.

Introduction

When a Kernel is designed for a multicore system, the shared memory must be protected of concurrent writing accesses. The memory's protection increments kernel code complexity and decreases operative system's performance. If one or more processors are having access to some data at the same time, mutual exclusion must be realized to protect shared data in multicore systems.

In a mono-processor multi-task system the scheduler often switch the task, so the unique risk is while the task is changing the information the scheduler take it out the cpu. The protecction is this case is easy: disabled the scheduler while the task is in a critical section and then enabled again.

In a Multiprocessor system that solution can't be implemented. When we have tasks running in parallel, two or more tasks may execute the same line in the same time; Hence, the scheduler state doesn't care.

Resources protection

For protect resources in a multiprocessing system we need to define atomic operations. These are implemented in just one assembler instruction but several clock cycles.

Atomic operations

In every processor, write and read operations are always atomic. This means that when the operation is executing nobody is using that memory area.

For certain kind of operations the processor blocked the memory, with this purpose is provided the #Lock signal that it is used for critical memory operations. While this signal is high, the calls from other processors are blocked.

Bus memory access is non-deterministic; this means that the first one processor gets the bus. All the processors compete for the bus, then in a system with a lot processor this is a bottleneck.

But, why do we need atomic operations? Supposing that we have to increment a counter, the pascal's source is :

counter := counter +1;

If this line is executed at the same time, in several processors, the result will be incorrect if it is not atomic.

The correct value is 2, using atomic operations the processors access to the variable once per time and the result is corrected. The time to the sincronization increments with the number of processor. The common atomics operations are "TEST and SET" and "COMPARE and SWAP".

Impact of atomic operations

In system with a few processors, atomic operations does not represent a big deal and they are a fast solution for shared memory problem; However, if we increment the number of processors then we make a bottleneck.

Supposing a computer with 8 cores and with 1.45 GHz [1], while an instruction average time is 0.24 ns, atomic increment spends 42.09 ns. The time wasted making lock becomes critical.

[1] Paula McKenney: RCU vs. Locking Performance on Different Types of CPUs.
http://www.rdrop.com/users/paulmck/RCU/LCA2004.02.13a.pdf, 2005

Memory organization in a multicore system: Conclusion.

2011-04-05T15:35:00.000-07:00

From programmer point of view, the access to local and remote memory is transparent. An NUMA could be implemented in a SMP system without any problem. However, the OS must do an efficient memory assignation for improve these technologies.
In the case of SMP, memory administation is easy to implemented while in NUMA is not. The system has to assign memory depending of the cpu where the process is running. Every CPU has an own memory bank. The system performance is poor if there are more remote access than local.
Windows has supported NUMA since 2003 version and Linux since 2.6.X. Both of them gives syscalls to exploit NUMA.
TORO kernel is optimized for NUMA technologies, keeping in mind the moderns processors. The unique way to support NUMA is using dedicate buses. In the high performance environment these improves mustn't forget.

Matias E. Vara
www.torokernel.org

e1000 driver for TORO

2011-03-13T04:44:00.000-07:00

I have just started the implementation of e1000 driver like Intel Gigabit or compatible. I am using Minix 3 source and qemu as an emulator (Begin 0.12.0 version it supports e1000 emulator). The detection procedure is complete as you can see in the picture, It is uploaded to SVN.

Saludos!
Matias E. Vara
www.torokernel.org

Memory organization in a multicore system II

2011-03-06T04:42:00.000-08:00

Continuation of the article Memory organization in a multicore system.

Non uniform memory architectures.

In a NUMA system the processors have assigned a memory region, it access more fastly that others to it, however every procesor can access to every memory position. It is used message passing to remote memory access. The programmer see a continuos memory space and the hardware makes that abstraction.

The first one in the NUMA tecnology was Sequent Computer Systems. They introduced NUMA at '90. Afterwards it was acquired by IBM and the tecnology was implemented in Power processors.

In other way, IBM made it own NUMA implementation called SE (Shared Everything). This implementation is presented in Power6 processors.

The Intel NUMA implementation is called QuickPath Interconnect. It allows to share memory between the processors and it is transparent for the Operative System. Each processor has a point to point controller.

AMD implementation uses fast links called "Hypertransport Links". In this implementation each procesor has a memory controller and a local memory. The processors are connected between them through a coherent Hypertransport link. Futhermore, each processor has a bi-directional no-coherent bus for IO devices.

Using Point-to-Point controller, the processor can access to memory region more fastly than other and there is an important latency if it tray to access to remote memory. In this way, we have two kind of memory: Local Memory and Remote.

Matias E. Vara
www.torokernel.org

Memory organization in a Multicore system

2011-01-15T10:45:00.000-08:00

This paper is a part of the final project called "Parallel Algorithm with TORO kernel", Electronic Engineering, Universidad Nacional de La Plata. In the next months I will publish more papers about my final project. Enjoy!

Memory organization in a Multicore system

Actually, the "Uniform memory access" is the common way to access the memory (See SMP). In this kind of arquitecture, every processor can read every byte of memory, and the processors are independent. In this case, a shared bus is used and the processors compite but only one can write or read. In this environments just one processor can access to a byte in a gived time. For the programmers the memory access is transparent.

In 1992 Intel made the first SMP processor called Pentium PRO. And the memory bus was called Front Side Bus.

That is a bi-directional bus, it is too simple and very cheap, and in theory it scales well.

The next intel step was partition the FSB in two independent bus, but the cache coherency was a bootle-neck.

In 2007 it was implemented a bus per processor.

This kind of architecture is used by Atom, Celeron, Pentium and Core2 of intel.

In a system with many cores, the traffic through the FSB is heavy. The FSB doesn´t scale and it has a limit of 16 processor per bus. So the FSB is wall for the new multicores technology.

We can have CPU that it executes instructions fastly but we waste time if we can´t make the capture and decodification fastly. In the best case, we lose one cycle more reading from the memory.

Since 2001 the FSB has been replaced with point to point devices as Hypertransport or Intel QuickPath Interconnect. That changed the model memory to non uniform memory access

Matias E. Vara www.torokernel.org

x86 rings protection on Toro

2010-12-30T21:12:00.000-08:00

In x86 arch there are 4 ring levels. Ring 0 is the most privileged level and ring 3 is the least. In a OS the kernel runs in ring 0 and the user application runs in ring 3.

Ring 0 descriptors are used by the kernel and ring 3 descriptors are used by the user. The GDT supports up to 8192 descriptors but the OS just uses 4, two for kernel´s text and data, and two for user´s text and data. With these descriptors the kernel can access to all memory, for example 4GB in 32 bits.

When the OS uses privileged levels the processor has to check if every operation is valid, these mechanisms adds latencies. In a multitasking OS protection is essential and it protects the kernel code and data.

But what happens with dedicated multithread application? It runs alone in the system and it was written carefully, we need protection in this case? guessing that, we can reduce a lot the OS.
For example, if we want to implement syscalls, we don´t need traps. If the kernel and user application are in same ring, we just may use “call” instruction to kernel´s function. Actually, OS are using interruptions for support syscalls but they are too expensive. Don´t forget that we are jumping from ring 0 to ring 3.

In other way, when we are running user application and a interruption happens, the processor has to jump from ring 3 to ring 0, that is too expensive. In general cases a kernel procedure handles the interruption. If the user application runs in the same level that the kernel, we don´t spend time in latencies.

On TORO, the kernel and user application run in ring 0. And cause the kernel and app are compiling together, the syscalls are implemented easy. It just uses “call” instruction.

Matias E. Vara

Old TORO

2010-11-26T17:38:00.001-08:00

Since 2006, the year in which TORO objectives were modified, the TORO OS project corresponding to the version 1.xx was discontinued. These versions achieved a great success in terms of functionality. The most stable version was 1.1.3, sometimes I see the source of those versions and I feel very sorry of have abandoned it, however it was impossible to me to continue with both projects simultaneously. So I decided to make a small tribute to those versions. For that i will show next how to test TORO 1.1.3 through BOCHS. I've put some screenshots for you to observe the beauty of a shell in PASCAL. Enjoy it!

For these simulations is necessary x86 Bochs, remember that the 1.1.3 version is only for 32 bits. Here I include the torobch.bxrc file contents.

megs: 256

romimage: file=BIOS-bochs-latest, address=0xf0000

floppya: 1_44=toro-1.1.3.img, status=inserted

boot: floppy

It is necessary to download the toro-1.1.3 image from the link:

http://sourceforge.net/projects/toro/files/images/toro-1.1.3/toro-1.1.3.img/download

If everything is allright, the first window you will see when execute BOCHS will be:

Corresponds the GRUB bootloader, there you select TORO-1.1.3 and press enter.

It will start to load the OS and then the Shell:

We are ready to enter commands on TORO. The first command we will see is the ls that, as you already know, lists the actual directory.

Now we go to the directory where finds TORO's source using cd.

And we are going to run echo printk.pas, this will display the file content on screen.

You can see all Shell commands at /BIN directory, these are:

Running reboot the system is closed and we can turn off the virtual machine.

I hope you enjoyed it, make your own experiences running commands. You can also burn the image in a 3 ½ floppy and try it in a real machine.

Attention: Versions 1.x.x have no relation with version 0.xx, they are different things.

Matias E. Vara

www.torokernel.org

Toro Builder uploaded!

2010-11-20T15:38:00.000-08:00

I uploaded the new interface for Toro developing. You can compile and debug the kernel easy using ECLIPSE and QEMU, for download go here but first read the new WIKI for more information. I am working hardly for write usefull information.
If someone wants to be an EDITOR of WIKI contact me to torokernel@gmail.com, saludos.

Matias E. Vara
www.torokernel.org

Context Switching

2010-11-10T15:44:00.000-08:00

In this article I will try to make a brief description about “Context Switching” and specially how TORO implements it since version 0.01. I won’t talk about how TORO OS implements it in versions 1.xx, I’ll just say that it uses “Context Switching” by hardware. In future articles I will show the implementation of these ideas on pascal. If you have doubts, see the references! Enjoy it!

As we know, in kernel, the scheduler is in charge of thread distributions. A part of implementing the scheduling algorithm it performs the "Context Switching" procedure. When selects a new thread, the scheduler fills the processor registers with the values that they had just before the thread invokes the kernel (NOTE this comment is related with TORO’S scheduling algorithm, which is the cooperative thread).

Figure 1. Procedure for loading a new process.

In the x86-64 architecture some of the general use registers are RAX, RBX, RCX, etc. In addition to these registers, some system registers must be also updated, like CR3. These ones store information about the thread page directory that will be loaded. The procedure is named "Context Switching " and is a critical operation because it runs continuously so it must be very fast.

The “Context Switching” procedure can be implemented by software and by hardware.

When it’s implemented by hardware, it uses the mechanisms that provide a particular architecture for make the “Context Switching “. For example, for the x86 architecture, are used the structures named “tasks descriptors”, these ones are in the GDT (Global Descriptor Table) and when a new task must be loaded is simply used the instruction "call" to the task descriptor (called in the literature as TSS) [1].

On the other hand, in the implementation by software the “Context Switching” is done "by hand" and is a routine written by the programmer the one in charge of saving the value of the registers.

At first glance the “Context Switching” by hardware seems to be the best option because the programmer isn’t involved and is done "automatically". Often, in the “Context Switching” by hardware, registry values are all saved, but sometimes are not being used all records. That’s why the implementation by hardware may not be the best option.

For this reason the “Context Switching” in TORO is implemented by software, programming techniques are used for not using the “Context Switching” mechanism that offers a particular hardware. When the scheduler selects a new thread, it loads in the processor's registers the values corresponding to the new thread, and then starts run. The thread begins its execution after the moment when the SysThreadSwitch procedure was called.

As the “Context Switching” is always done after invoke the SysThreadSwitch function, the planner supposes that at that moment the processor's registers are not being used by the user application. In this way it's limited only to save the state of the stack's thread that has to be removed. For the implementation on x86-64 architecture, this is achieved by saving on the TThread structure the RSP registry value, wich keeps its position inside the stack.

The “Context Switching” implemented in TORO is faster than the one by hardware and the one implemented on an OS for general purposes. The selection of the “Context Switching” method is directly related to the cooperative thread model.

Therefore the utilization of “Context Switching” by software adds portability and speed [2].

[1]. Intel. IA-32 Intel® Architecture Software Developer’s Manual. Vol3. 2004.

[2]. Osdev Wiki, Context Switching, http://wiki.osdev.org/Context_Switching.

Matias E. Vara

www.torokernel.org

Changes on SVN

2010-11-08T18:59:00.000-08:00

I ´ll work on SVN directories so maybe it ´ll be off-line a few hours. You should make an update on SVN.

Saludos
Matias E. Vara
www.torokernel.org

BugCon Presentation

2010-10-28T14:34:00.000-07:00

Here it is the link to Toro´s presentation on BugCon2010. Enjoy!
Saludos.

PD: The presentation is in english. Thanks Eugene!

Matias E. Vara
www.torokernel.org

Threads migration without Lock in Toro

2010-09-19T19:58:00.000-07:00

In a Multicore environment, the programmer needs to create local and remote threads. In TORO create a remote threads is easy, you just have to use BeginThread() with the appropriate CPU identification. On that basis, there are two important procedures in TORO:

- Thread Emigrating: is when the threads are created in a remote processor.
- Thread Inmigrating: is when the guest processor enque in its scheduler the threads that they are comming from others processors.

This is the unique kernel point which needs syncronization between the cores. The mechanism is called "Exchange Slot" and it works without any atomic operation. In this case it used for send and receiv threads but it works with any kind of data.

For every processor in TORO there is an structure called TSchedulerExchangeSlot:

TSchedulerExchangeSlot = record
DispatcherArray: array[0..MAX_CPU-1] of PThread;
EmigrateArray: array[0..MAX_CPU-1] of PThread;
end;

Where MAX_CPU is the number of processors and PThread is a pointer to TThread structure. From the structure declaration we can see that every processor has two arrays

(DispatcherArray y EmigrateArray), and every entry in the array is a pointer to a thread´s queu.

The procedure to send threads to remote processor has three stages:
1-The user calls to BeginThread()for create a new one, if the parameter CPUID is different to local CPU then the kernel enque it to DispatcherArray[CPUID].
2-During Scheduling (cause SysThreadSwitch syscall). The procedure Emigrating()moves all threads from DispatcherArray[] to EmigrateArray[] (only if EmigrateArray[] is nil)
3-During Scheduling of the Remote CPU, the procedure Inmigrating() look for a not nil entry in EmigrateArray[LocalCPUID] in every TSchedulerExchangeSlot processor structure. If it is not nil Then import all the threads to local scheduler and become EmigrateArray[LocalCpuid] to nil.
Local processor just writes and read to DispatcherArray[]. While the local and remote processor write and read to EmigrateArray[], but the access is synchronized using nil pointer.
The “Exchange Slot” doesn´t need "LOCK" instruction.

The Inmigrating and Emigrating procedures are called from the Scheduler. The scheduler makes a few system task, for example in the picture, we can see the scheduler´s flow diagram. There, first it calls Inmigrating(), after that it calls Emigrating() and At the end a new thread is scheduling.

Matias E. Vara
www.torokernel.org

Toro in BugCon 2010!

2010-07-22T18:17:00.000-07:00

I 'll be present in BugCon 2010 meeting, Mexico DF. I 'll talk about the problems of Modern Systems on Multicore environment and How Toro fixes them . Also I 'll compile and test toro step by step using Eclipse and QEMU. You can see others speakers here .
Saludos.
Matias E. Vara
www.torokernel.org

Testing TORO using QEMU and ECLIPSE on Win64

2010-04-12T06:43:00.000-07:00

I uploaded a video .

It shows an environment to compile and test toro fastly through Qemu and Eclipse.I 'll upload a good tutorial in few weeks. In other way I was making a release with all the tools necessary to compile and emulate TORO.

Saludos
Matias E. Vara
www.torokernel.org

Testing TORO using ECLIPSE+QEMU

2010-04-05T20:10:00.000-07:00

Hi!, I was looking a good tool to compile and test toro fastly . I found it , I am testing Eclipse + Qemu in Ubuntu for 64 bit and I could run toro step by step and others things.
I am using a plug-in (Pascaline) for support Pascal lenguaje on Eclipse.
Here you have a few screen , but at the moment It doesn't work at 100% .

Qemu's session.

Saludos.

Lazarus + GDB + QEMU

2010-01-07T08:23:00.000-08:00

I am working hard to obtain a plataform to compile, run and test TORO fast. In this way I am doing a few modifications on Lazarus' source . Lazarus is an excelent IDE for Freepascal Compiler.
The BUILD program was included into Lazarus , So when you do "RUN" Lazarus makes :
- toro.exe
- ToroImage.img
- Run Qemu
- Debug TORO using Lazarus (GDB client ---> QEMU GDB Server) .
Lazarus can be compile to Linux or Window so It is easy to test TORO in both plataform.
Saludos.
Matias E. Vara

CPU Cache Managing

2009-10-27T18:47:00.001-07:00

I was working on a few procedures on Arch Unit to give access to L2 Cache. In the first moment the whole kernel is market as cacheable , but It's a decision of the user mark others memory region as cacheables. If we know which memory regions are too usefull we can caching just these regions and we are more eficient to access to memory.
Anyway I am working on syscalls in the Memory Unit for do that in a easy way.
The lastest source is uploaded on SVN.
Saludos
Matias E. Vara

Compiling TORO On Linux II

2009-08-26T20:45:00.000-07:00

I have uploaded to SVN the modifications on Build for support ELF files and make the boot's image on Linux. Build takes the executable file (PECOFF or ELF) and convert it to ToroImage.img .
The step for compile it are :
1 - Do an update on SVN's folder
2 - Run on terminal "sh compile.sh"
3 - That's all , you must have installed fpc for Linux-x86-64 . I tested using 2.2.4 version and it works fine. If the process was rigth the result is ToroImage.img and you can test it using QEMU like in window's version .
Maybe you 'll have got to edit compile.sh for corrects the path of build and fpc.
I am listenning any opinion .

Saludos .
Matias Vara.

Compiling TORO on Linux

2009-08-23T14:21:00.000-07:00

I have uploaded to SNV the Toro's source with the modifications for compile it on Linux using FPC 2.2.4 for x86_64. The script compile.sh makes an ELF file.
I am still working on Build for translate the ELF to image as It does with PECOFF64 on Windows. Saludos.
Matias E. Vara

Implementation of Mutiplex-IO At the level of Network Unit

2009-08-10T18:57:00.000-07:00

I have uploaded the first beta version of Network Unit with no-blocking Apis in order to reduce the number of context switch and the number of threads used to listen network connections.
I promise upload the Programmer and Compilation documents soon.
Saludos .
Matias Vara.

Taskfreak! implementation.

2009-05-30T19:35:00.000-07:00

I implemented the task manager Taskfreak! . There , i wrote all the tasks that i am working and the features of future versions.
Enjoy!
The link is .

Multicore done!

2009-05-19T19:20:00.001-07:00

I uploaded to SVN the last version of TORO. I added Multicore detection and It was tested on Intel x86_64 arch fine. I have fixed bugs in Memory detection , now I am using in15h to get information about memory .

Wainting opinions!

2009-03-31T20:57:00.000-07:00

I am rewritting the Manuals for Compile and Test TORO , i am thinking in upload it in the wiki of Sourceforge. Any opinion will be accepted .
Saludos
Matias E. Vara.

Toro's code in SVN!

2009-02-18T13:18:00.000-08:00

I uploaded the version of Toro that i am working , i think that is good manner to shared the source code and not wait for a packet in the filerelease. The link is here or you can acces from sf page.
Enjoy!.
Matias E. Vara .

Compiling TORO with FPC 2.2.3

2008-07-13T16:14:00.000-07:00

I worked in file system.pas for compile TORO using FPC 2.2.3 . Now Toro can be compiled using last version of FPC 2.2.3. I started with the RTL of Win64 and was reduced only with necessary source .This implementation will present in next Version .
Un saludo Matias Vara .

Toro 0.03 ready!

2008-03-25T13:47:00.000-07:00

Stack TCP-IP and supports for ethernet network card.
Drivers for ne2000 ethernet card .
Support for FPC 2.2.1
Solved Bugs in Process.
Solved Bug in EXT2 Drivers.
Solved Bugs in Arch.
Others Bugs solved .

TORO speaks!

2007-12-30T09:32:00.001-08:00

Some results about Stack TCP-IP , i have time for write in my holidays .
In the pictures you can see as toro responded a telnet , i think that in few weeks the next version will be ready , please wait .
Un saludo Matias E. Vara

Translation of paper

2007-10-20T08:49:00.000-07:00

Hello here you have the translation of paper published in SL Ezine. Enjoy.

Current modern systems in which the parallelism and multiprocessing have reached their limits, requires programmers to think on new methodology in order to maximize the performance of actual hardware. Here I will try to discuss two issues for the operating system with high-grade of multiprocessing : access to the memory bus and access to shared resources.

The main issue regarding memory performance appears when a lot of processors want to access concurrently to memory through a shared memory bus. One solution to reduce the contention at the memory bus level, is the implementation of a memory controller such as AMD HyperTransport technology, every processor has its own integrated memory controller to access dedicated region of memory faster. Thus, accessing memory region that are not adjacent to the CPU hit small penalty and require 1 or 2 hops.

These controller are implemented using a NUMA model (Non Uniform Memory Access). Such architecture requires that the memory allocator at kernel level of the operating system must be re-written. When a thread running on a specific CPU, the memory allocator module of the OS is in charge to return a free block of memory located in the dedicated region handled by the processor.

Optimizing access to memory such way, brings subsequent problem on the table: accessing to shared memory. One way of solving such issue can be handled by implementing atomic operations (using a specific “lock” instruction). The lock instruction prevents other CPUs to access the same region of memory, and indirectly prevent other CPUs to access the memory bus at all while performing the operation. The protection can be implemented using a lot of “locks” but the system performance degrades rapidly, which becomes obvious as more processors attempt to access the shared resource.

One solution is to dedicate resources to processors, where resources are Block Devices, Net Devices or FileSystems. This requires some sort of protection run at level of local processor handling the resource. This can be handled in a nice and easy way by implementing a Round Robin Scheduler also known as Cooperative Threading Scheduler.

At this level a new issue rises on the table : the communication between processors. When sending message from one CPU to another, in order to prevent the use of atomic lock instructions, the communication system can be implemented using a matrix, where every processor has an array of slots referencing every single other processors. When a slot #N is set to “null”, it is interpreted as the CPU #N has not set a message to be imported by current local CPU. When CPU #N needs to sending a message to CPU#1, it will set its slot #N, which is then switched by CPU#1 to be imported and finally reset to “null”. The communication system can be extended from this simple base.

The new technologies are powerful when a NURA model is implemented at kernel level of the operating system (Non Uniform Resources Access).

An example of such technology is implemented in the Operating System TORO, available at http://toro.sourceforge.net

TORO is demonstrating an innovative operating system by integrating at the same ring level both kernel and the user application server. The threads of the user application server are distributed evenly on all CPUs and running independently in parallel.

The memory model chosen is NUMA without pagination.

During the initialization, the memory is divided proportionally for each processor installed on the system. When a thread needs memory, the memory allocator returns a free block of memory depending on which CPU the thread is running.

In the same way, TORO can dedicate resources to specific processor, i.e. a FileSystem. This only CPU then can access to this instance of FileSystem.

The scheduler is based on the cooperative threading model, therefore due to this design, TORO can migrate threads between CPUs and send messages between threads without using any lock instruction.

TORO is well suited for integrated system to run at high pace application servers like web servers, database servers. The neat part for programmers is to be able to compile application server embedding the kernel of the OS, meaning that when the system operates, the application server runs in kernel mode beside the kernel and at the same ring level, providing direct access to all resources without any overhead, and therefore maximizing performance for the overall system.

Matias E. Vara

Paper about Operative System

2007-10-01T19:13:00.000-07:00

Hello i written a paper in SL Ezine , you can download here ,
Bye Matias Vara .

Working on TCP-IP Stack

2007-07-20T17:52:00.000-07:00

Hello, now i am working on Networks Drivers structures and TCP-IP Protocol Stack, all include in version toro 0.03
Un saludo Matias Vara.

Toro 0.02 released

2007-05-15T21:50:00.000-07:00

Toro 0.02 is ready !. New Virtual FileSystem and drivers for ATA Disks and EXT2 FS.
For compilation download the new documentation from http://toro.sourceforge.net .
Un saludo Matias Vara.

Toro 0.01 !

2007-01-27T13:38:00.000-08:00

New Version of TORO the changes are here , I will upload in next days for compile TORO step by step .
Un saludo Matias Vara.

Some Screen

2007-01-24T15:06:00.000-08:00

Some ScreenShot about TORO 0.01 booting in AMD X86-64 with SMP in QEMU :
https://sourceforge.net/project/screenshots.php?group_id=109734&ssid=51547

Compiling Toro 1.1.3

2006-05-20T15:08:00.000-07:00

First you must download the last zip of toro , it is toro-1.1.3-src.zip , you can download it from toro.sourceforge.net .

Next you must unzip the packet in the disket-formating with GRUB , for the moment

Toro only have the driver for floppy ( in the future it will have drivers to SATA disk)

Next go to /usr/toro-src/ and execute “make” , here you are compiling the kernel .

Immediately go to /usr/tools/sh and do “make” , do “make” in usr/tools/ls , usr/tools/mkdir , here you are compiling the utilities .

Ready! , you have the diskette-boot for Toro .

You can boot Toro using bochs or from diskette in real machine .
Simple bochsrc.txt file , it works in Bochs-2.2.6 .

floppya: 1_44=a:, status=inserted
megs: 16
floppy_command_delay: 200
boot: floppy

Important! :

The file /usr/toro-src/make.rules have the path of utilities , you must modify .
The linker “ld” must can output “elf-i386” executable file , I don’t know if the ld include in fpc for windows can do that .

Please tell me if you have any question .

Bye Matias Vara .

P.D. : Here you can download the minimal version of fpc 1.0.6 for go32v2 and ld linker , it works with cygwin 2.427 or last .

Sorry

2005-11-01T15:25:00.000-08:00

at the moment will let post in this blog, if somebody wants to translate the forum torokernel.blogspot.com i will been thankful.Matias Vara

Toro compiled on fpc-linux

2005-08-19T18:32:00.000-07:00

The available package zip of Toro-1.1 to be already compiled on last version of fpc on linux. Matias Vara

Version 1.1

2005-08-01T18:58:00.000-07:00

The new version of toro have two packets , one zip , it have all code and it is ready for compiling . The second packet is a 3 1/2 floppy disk image and it is ready for boot .
I am waiting yours comentarys . Bye . Matias Vara