Ponernos deacuerdo en cosas basicas
Belial & Grimoire
la primera es, deacuerdo con Khronos, menciono que se le facilitarian
mas las cosas si compilara el kernel en Window$, ya compilado pues no
hay problema para que se ejecute todo bien, pero si es el codigo
fuente creo a veces habra problemas al intentar compilar ya que por lo
menos yo uso linux.
solo lo menciono porque al leer un poco AceOS, no pude hacerlo
trabajar porque habian cosas que eran diferentes por ejemplo
LibDir = c:\djgpp\lib\gcc-lib\djgpp\3.1
si cosas asi llegan a pasar, que haremos?, vamos a virtualizar algun
sistema operativo window$, podremos trabajar en linux tambien, o mejor
haremos las cosas en un solo sistema operativo?
si virtualizamos uno, cual usaremos? Windows 7, XP o cual seria mas
facil para todos?
Ustedes creo van un poco mas adelantados en esto que yo, asi que me
gustaria saber si van a poner aqui las cosas que estan haciendo o
quieren hacer para el kernel... no me gustaria hacer algo y darme
cuenta que ya alguien mas lo hizo, por eso quisiera saber si cada
quien dira lo que hace y cuanto lleva y apoyarnos si es posible?
y como duda, he visto que hay que hacer todo con el kernel verdad?,
para un printf hay que hacer un stdio.h y un printf.c, o por lo menos
eso es lo que estoy viendo, pero bueno, aun no se bien, asi que me
podrian decir si en eso estoy bien o mal?
bueno, ojala cresca esto y seamos una gran competencia para linux XD
bueno que esten bien y ojala pueda dar mucha participacion, de todas
formas ya estoy leyendo todo lo que puedo, espero sirva bastante
jeje, salu2
Dario Rodriguez
Yo uso Linux tambien, y como mencione antes, creo que es lo más
conveniente. ¿Porque? Porque planeamos implementar POSIX en Mythos y,
a la larga, será un sistema de tipo UNIX. No importa si se asemeja más
a los BSD, a Hurd o a LINUX, lo que destaco es que las herramientas de
desarrollo que utilizaremos cuando Mythos se deasrrolle dentro de
Mythos serán herramientas Unix.
No obstante, no es imposible hacer que podamos desarrollar en un
ambiente tanto como en el otro. Si Khronos y/u otros desea(n) poder
compilar Mythos en Windows, deberán mantener los archivos necesarios,
tanto como la documentación pertinente, como los maintainers del
desarrollo de Mythos en Windows. Les comentaré que se puede usar GIT
desde CygWin, o desde el proyecto msysGit, con TortoiseGIT como
front-end. No se si sea lo más estable, pero podrán integrar las
mismas formas de trabajo. El tema de los paths de compilación y demás
se arregla con Makefiles y preprocesador.
Insisto, para mi lo mejor es trabajar en Linux u otro sistema Unix
like, pero no creo que sea necesario dejar fuera del desarrollo a
quien quiera extender y compilar en otras plataformas. El main target
para mi, será siempre que los Unix like lo compilen sin problemas,
porque eso lo hará más fácil para compilarse dentro de si mismo (a
futuro).
Respecto a esta duda:
> Ustedes creo van un poco mas adelantados en esto que yo, asi que me
> gustaria saber si van a poner aqui las cosas que estan haciendo o
> quieren hacer para el kernel... no me gustaria hacer algo y darme
> cuenta que ya alguien mas lo hizo, por eso quisiera saber si cada
> quien dira lo que hace y cuanto lleva y apoyarnos si es posible?
Esto entra en la categoría de Source Code Management o como deseen
llamarle, y es donde entra GIT. Luego de clonar el repo master de
GitHub, la branch master es tu forma de mantenerte al tanto. No
tocaras esa branch para codificar, sino que sacarás ramas desde ahi, y
nos mandarás los parches correspondientes a la lista, por ejemplo:
"Parche: funcion strlen reescrita". Los parches se sacan con git
format-patch, ejemplo:
git format-patch -o "/path/to/patches" -1
Saca un parche que representa el último commit y lo deja en
"/path/to/patches". Cuando alguien manda un parche, nos toca
revisarlo, para eso lo copiamos en un archivo de texto y usamos el
comando 'git am' (apply mailbox-patch) para aplicar el parche sobre
una nueva rama. Si Khronos tiene una rama iniciada en v0.1-dev01, y
crea a partir de ahi un parche que nos envía, entonces nos debemos
crear una nueva rama desde v0.1-dev01, y aplicar el parche. Los
parches tienen el SHA-1 (en vez de la version) del commit desde el que
fueron creados, para que sepamos donde aplicarlos. La rama en la que
aplicamos el parche sufrirá los cambios para que los probemos, sin que
nuestras ramas de desarrollo ni mucho menos la rama master sufran
cambios.
Yo soy el maintainer directo de la rama master, es decir que la rama
master que todos tienen es una replica de la que está en mi
repositorio local, en mi laptop. Ese repo hace 'git push' directo a
GitHub y desde ahi ustedes hacen 'git pull' o 'git fetch' (tambien
estan los forks de GitHub: http://help.github.com/forking/, pero no
los recomiendo tanto porque pueden confundir cuál es el repo
principal.). En otras palabras, cuando un parche llega a la rama
master de mi laptop, significa que se distribuirá a la rama master de
cada uno de ustedes. Para que yo admita cambios en master, debemos
discutirlos en la lista y, llegados a un acuerdo, los incluiré. Al
menos una vez al día deberian actualizar la rama master para tener los
ultimos cambios y puedan comparar con lo que estan haciendo.
Obviamente algunas cosas que se hagan en local quedarán sin incluirse
nunca en el repo principal, para eso tenemos maintainers y discutimos
los cambios. Espero que nadie se asuste por enviar un parche y que
este no se incluya en main, o sufra modificaciones, cosa que siempre
sucede y lo verán en las listas de GIT o LINUX (LKML).
El no pisarnos los desarrollos depende de la inteligencia con la que
cada uno trabaje. Si no actualizas master, modificas todos los
fuentes, y tratas de poner tus modificaciones un mes después en el
repo, entonces master no estara igual y será más difícil aceptar tus
cambios que cambiar todo de nuevo a mano. Entender el modelo de
desarrollo distribuido es la base de hacerlo bien. Cada uno luego
contara con sus colaboradores para ramificar el flujo y que no caiga
todo sobre mi como maintainer principal. Por ejemplo, un maintainer
del boot se ocupará de esa parte y yo siempre confiare en los parches
que me mande dado que no soy el responsable. Si hay un error en esos
parches, sera el maintainer el responsable de haberlo visto/probado, y
sus colaboradores.
Sobre tu ultima duda:
> y como duda, he visto que hay que hacer todo con el kernel verdad?,
> para un printf hay que hacer un stdio.h y un printf.c, o por lo menos
> eso es lo que estoy viendo, pero bueno, aun no se bien, asi que me
> podrian decir si en eso estoy bien o mal?
Efectivamente, el kernel tiene que contar con todo, y debemos
diseñarlo con tiempo. Aún falta la administracion de memoria virtual,
paginación, sistemas de archivos, cargadores de ejecutables, proceso
INIT, etcétera. Podríamos, como un ejercicio, compilar MINIX,
probarlo, analizarlo, ver las cosas que no nos gustan, y usar las
buenas ideas, implementándolas a nuestra manera. Quiza podamos usar la
libc de GNU mientras vamos armando una del proyecto (si es que hay
equipo y quorum para hacer esto, porque creo que el kernel es lo
primordial). Lo mismo con algunas utilidades que no nos sentaremos a
codificar porque ni siquiera representan un desafío, etc etc... Lo que
sí se puede hacer es armar un sistema de gestion de paquetes, y uno
para el kernel.
Quiza sea buena idea encarar el proyecto con una idea de microkernel.
Tengo la idea de un sistema donde se pueda actualizar/cambiar un
módulo X desde un gestor de módulos del kernel, con una fase de
validación anterior a la carga efectiva y un sistema similar a los
ports, con la posibilidad de actualizar el repo, compilar un modulo, e
instalarlo con un simple 'make update-fatfs'. Esto son ideas que
obviamente tendrán su tiempo y su momento para ser implementadas (o
rechazadas), y aún tenemos todo por construir, así que las ideas y
diseños serán la linea a seguir en el desarrollo.
Finalmente:
> bueno, ojala cresca esto y seamos una gran competencia para linux XD
No una competencia, pero si una gran fuente de nuevas ideas!
Saludos a todos.
2011/2/24 Belial & Grimoire <tea.ma...@gmail.com>: