Creo que me malinterpretaron algo:

Mencione que *compilarlo* en LINUX es buena idea, no hable de copiar Linux. Aún así, "bash" no es parte de Linux  

Por otro lado, remarcar algunos puntos:

Si se planea usar POSIX en el futuro, obviamente no lo tendremos en cuenta para elaborar las internas del planificador o el loader (Sencillamente no forman parte de POSIX). Pero se debe tener en cuenta el estándar que se pretende cumplir antes de tener qué corregir para cumplirlo, o al menos me parece lo más sabio.

El desarrollo del kernel, por su parte, no tiene porqué depender del desarrollo de un Loader. Quienes quieran dedicar tiempo a crear un loader propio, bienvenidos sean, y trabajen libres en ese área, pero si el kernel bootea desde GRUB y los demás quieren meterle tiempo a desarrollar otras cosas, deben ser libres de hacerlo. Modularizar es también descentralizar, y eso significa que definitivamente no iremos todos juntos sabiendo cada cosa que se escriba.

Documentos: Hay documentos técnicos detallados que explican el funcionamiento de cada parte. Hay documentos que explican el funcionamiento/finalidad de un módulo, hay otros para un subsistema. En principio: No aceptar código sin una estructura y documentación medianamente razonables. La filosofía que aprendí de Linus y Junio y creo, es aplicable a cualquier proyecto.

Compilador: Se puede tener un márgen de aceptación, donde gcc debe poder compilar.

GDT e IDT son tablas de descriptores. La IDT guarda las interrupciónes que serán parte del núcleo. Funcionalmente, carguemos de donde carguemos, la IDT deberá setearse, así que no es parte del loader.


Khronos14: Pasame ese código a soft.d4rio en GMail y seguimos en contacto

Tiren un nombre y creo un proyecto en GitHub.

¿Alguien más que esté familiarizado con el flujo de desarrollo distribuído clásico de GIT con parches y redes de confianza?  De otra forma puedo encargarme de la administración de esta parte (al menos por ahora).

También se necesitarán maintainers. Al inicio basta con que el kernel pueda correr el proceso INIT, así que el planificador de tareas no necesita capacidad de planificar. Hay que ver qué partes se desarrollan, y en mi opinión, el code de FreeBSD es siempre una buena referencia si no se sabe que hacer.

Por ahora me parece buena idea compilarlo en LINUX, ya que al fin y al cabo, si se implementa POSIX usaremos un Shell UNIX y Makefiles.

Por cierto, soy partidario de documentar y llevar bien armado el diseño antes de meterse a hacer código. Prefiero un thread de 50 mails para decantar en una solución concreta y correcta de un problema, antes que 10 veces modificar lo mismo por picar código.

Se aceptan nombresss y documentos. De otra forma esto va a quedar en lo mismo que los anteriores.

Hi again boys,

Hoy me puse a curiosear por el foro, y veo esto. Como saben, tengo un poco de code de BootSector, pero no tiene nada relacionado a carga del kernel ni sistema de archivos.

En mi opinión, si alguien tiene la documentación de lo necesario para bootear desde GRUB es lo ideal, sino está el boot de FreeBSD que está bien armado.

Se debería abarcar C desde el principio, con esto quiero decir que podría usarse el código de Minix hasta el seteo del main() de INIT. Después el Kernel y lo demás se van diferenciando.

Si va a ser un proyecto para aprender, divertirse y joder un poco, hagámoslo seguro y bien friki. Los microkernels son para que el usuario cargue cosas en caliente. Podemos hacer un monolítico y diferenciar bien la kernel-land para hacer que el sistema completo sea caprichoso.

Bueno, acá tienen a alguien para ANSI C, ensamblador, algo de x86 y organizacion.

Por cierto, sigue mi invitación a que se use GIT. Lo estoy usando en la empresa, para los proyectos que me toca llevar, y la verdad es que GIT hace la vida más fácil. Ya portaré mi lenguaje (aún gestandose en C) a este nuevo SO cuando se pueda.

Saludos!

Usa readline de GNU

Hola, de vuelta al foro (por ahora que estoy de vacaciones aunque sea) y un intento de cooperación un mes después del ultimo comentario, espero que valga, a ver:

Respecto a la función de limpiar la pantalla:

En un entorno Windows:

La primera seria un system("cls"), que es lo que usa ahora, y la segunda opción:

 /* Standard error macro for reporting API errors */ 
 #define PERR(bSuccess, api){if(!(bSuccess)) printf("%s:Error %d from %s on line %d\n", __FILE__, GetLastError(), api, __LINE__);}
 
 void cls( HANDLE hConsole )
 {
    COORD coordScreen = { 0, 0 };    /* here's where we'll home the
                                        cursor */ 
    BOOL bSuccess;
    DWORD cCharsWritten;
    CONSOLE_SCREEN_BUFFER_INFO csbi; /* to get buffer info */ 
    DWORD dwConSize;                 /* number of character cells in
                                        the current buffer */ 
 
    /* get the number of character cells in the current buffer */ 
 
    bSuccess = GetConsoleScreenBufferInfo( hConsole, &csbi );
    PERR( bSuccess, "GetConsoleScreenBufferInfo" );
    dwConSize = csbi.dwSize.X * csbi.dwSize.Y;
 
    /* fill the entire screen with blanks */ 
 
    bSuccess = FillConsoleOutputCharacter( hConsole, (TCHAR) ' ',
       dwConSize, coordScreen, &cCharsWritten );
    PERR( bSuccess, "FillConsoleOutputCharacter" );
 
    /* get the current text attribute */ 
 
    bSuccess = GetConsoleScreenBufferInfo( hConsole, &csbi );
    PERR( bSuccess, "ConsoleScreenBufferInfo" );
 
    /* now set the buffer's attributes accordingly */ 
 
    bSuccess = FillConsoleOutputAttribute( hConsole, csbi.wAttributes,
       dwConSize, coordScreen, &cCharsWritten );
    PERR( bSuccess, "FillConsoleOutputAttribute" );
 
    /* put the cursor at (0, 0) */ 
 
    bSuccess = SetConsoleCursorPosition( hConsole, coordScreen );
    PERR( bSuccess, "SetConsoleCursorPosition" );
    return;
 }

Fuente: http://support.microsoft.com/kb/99261

... también vi por ahi implementaciónes en inline ASM con llamadas de DOS, pero no las encuentro ahora.


Ahora bien, falta la implementación UNIX, que resulta ser un poco más... amena  :

#include <stdio.h>
 
int
main(void)
{
	printf("\033[H\033[J"); // Esto es to, esto es todo amigos
	return 0;
}

Fuentes:
  http://www.programmersheaven.com/mb/beginnercpp/137205/137377/re-clear--screen/
  http://homepages.cwi.nl/~tromp/tetris.html
  http://196.1.111.155/download_util/download/MODIFY07.txt?id=uniqueid
  http://okmij.org/ftp/packages/tournament-sched.c
  http://www.geekinterview.com/question_details/16718
  ...
  Y demás fuentes gratuitos que obtuve por ahi, en fin, el hecho es que funciona Ok, y debería funcionar Ok en cualquier terminal UNIX que use secuencias de Escape (desde LINUX, por los BSDes, AIX... bla bla bla)



Ahora bien, otro tema es que esta parte del code...

/*
* Para compilar en UNIX desactivar la definicion de WINDOWS y activar la de UNIX
* Para otros SO desactivar ambas.
*/
 
#ifndef WINDOWS
    #define WINDOWS
#endif
/* 
#ifndef UNIX
    #define UNIX 
#endif
*/

...resulta bastante "sucia" por así llamarle (y con todo respeto), ya que existen macros dadas para cada sistema (ver fuente http://msdn.microsoft.com/en-us/library/b0084kay.aspx), con lo que puedes usar _WIN32 y _WIN64 para definir un Windows, y cualquier otro sistema usara la secuencia de escape (si sale un Bug por ahi se solucionará, pero esa secuencia debe funcionar hasta en un BeOS)


Espero haber aportado suficiente

Un saludo Gente, Feliz 2010

@EI, rato que no me pasaba por aqui, un saludo!

Oh!! 

Eso lo entendi, pero la instrucción loop es precisamente para evitar usar un dec, un cmp un jump... es algo trivial, pero si se puede hacer mejor... just do it!

S2

@dark_hat:
Tenes toda la razon, pero... yo me referia el code que posteo >FedeX< en el que no se hace uso del EBP sino del ESP  ...
Precisamente porque normalmente el acceso a las variables es en la pila y usando EBP, pero como bien postea >FedeX<, en éste caso no es necesario y se puede dejar a EBP libre. 

@>FedeX< :
Normalmente las funciones solo modificarán el registro EAX, y para retornar datos >4bytes usarán punteros. De todas formas se puede guardar ECX en el stack si una función trata de modificarlo...

.comparo1e:
	DEC	ECX
	cmp	ECX,-1 ; <<<<<<<<<<<<<<<<< WTH!
	jne	.bucle

Pero para que usar ECX si vas a usar CMP??? 
Usa ECX y la orden LOOP  ... ese es el uso correcto por el que ECX es el registro contador...
Cuando tenga tiempo lo hago y se los paso... ahora estoy saliendo del trabajo..

bye guys!!

@>FedeX<: El problema con acceder a las variables subiendo por el stack es que no puedes mover el stack pointer de donde está, y si haces push o pop en algún momento todos los accesos a las variables deberían cambiar su offset respecto de éste.
De todas formas te falta inicializar una de las variables... fijate que es:

int v1[N]={2, 5, 7, 9, 10, 10, 9, 8, 7, 5};
int v2[N];
int x=0, suma1=0, suma2=0;

Con lo que son 10 inicializaciones para los valores del arreglo v1, más las tres inicializaciones para x, suma1 y suma2...

Igual es un buen aporte puesto que es totalmente válido hacerlo así... pero me pregunto ¿porque no haces el bucle usando ECX?.... esta mal codificado, pero el bucle es un for( x=0 ; x<N ; x++).

@ctlon: El code que pones no es ni similar al que se generaría, y por lo tanto no es correcto pasar el programa asi.... Debes crear la pila del main() para luego reservar los int e inicializar los datos inicializados al inicio. Para eso guardas la dirección de retorno y todo eso y luego de guardar ebp lo pones con esp.

A parte de eso creo que es bueno crear en la pila local 4 bytes de más para poner 2 punteros a los vectores... así es más simple acceder por subíndices, y también pasar los punteros como argumentos

Ahora que tienes la pila local a main reservas memoria... o sea restas 4*10 y 4*10 por los dos vectores, más 4*3 por las variables x, suma y suma2, y luego 2*2 por los dos punteros.
A eso le inicializas los datos con MOV y accedes a las variables por EBP.... 

Salu2