Hola a todos los que usais minix -
Estoy haciendo un sistema operativo (gratuito) (sólo un hobby, no será grande y
profesional como GNU) para 386 (486) AT clones. Esto se ha estado fermentando
desde abril, y está empezando a prepararse. Me gustaría algún comentario sobre
cosas que la gente gusta / disgusta de minix, ya que mi sistema operativo se parece un poco
(La misma disposición física del sistema de archivos (debido a razones prácticas)
entre otras cosas).
He portado bash en la actualidad (1.08) y gcc (1.40), y las cosas parecen funcionar.
Esto implica que tendré algo práctico dentro de unos meses, y
Me gustaría saber qué características mayoría de la gente desea. Cualquier sugerencia
son bienvenidos, pero no voy a prometer voy a poner en práctica :-)
                Linus (Torva...@ kruuna.helsinki.fi)
PS. Sí - es gratis de cualquier código de minix, y tiene un fs multi-threaded.
NO es protable (386 utiliza la conmutación de tareas, etc), y probablemente nunca
apoyará nada que no sea AT-discos duros, ya que es todo lo que tengo .

> He portado bash en la actualidad (1.08) y gcc (1.40), y las cosas parecen funcionar.
> Esto implica que tendré algo práctico dentro de unos meses, y
> Me gustaría saber qué características mayoría de la gente desea. Cualquier sugerencia
> Son bienvenidos, pero no voy a prometer voy a ponerlas en práctica :-)

Cuéntanos más! ¿Necesita una MMU?
PS>. Sí - es gratis de cualquier código de minix, y tiene un fs multi-threaded.
> NO es protable (386 utiliza la conmutación de tareas, etc)

¿Cuánto de ello se encuentra en C? ¿Qué dificultades que habrá en la transferencia?
Nadie va a creer acerca de la no transferibilidad , y yo sería un
como para transportarlo a mi Amiga (Mach necesita un MMU, Minix no es gratis).
En cuanto a las características, así, seudo ttys, sockets BSD, en modo de usuario
sistemas de archivos (lo que puedo decir cat / dev / tcp / kruuna.helsinki.fi / dedo),
tamaño de la ventana en la estructura tty, llamadas al sistema capaz de soportar
POSIX.1. Ah, y los nombres largos de archivo de tipo BSD.

Re: mi post sobre mi nuevo] OS
> Cuéntanos más! ¿Necesita una MMU?


Sí, se necesita una MMU (todo el mundo lo siento), y específicamente las necesidades de una
386/486 MMU (véase más adelante).
>> PS. Sí - es gratis de cualquier código de minix, y tiene un fs multi-threaded.
>> NO es protable (386 utiliza la conmutación de tareas, etc)
> ¿Cuánto de ello se encuentra en C? ¿Qué dificultades que habrá en la transferencia?
> Nadie le cree sobre la no transferibilidad , y yo sería un
> Como para transportarlo a mi Amiga (Mach necesita un MMU, Minix no es gratis).


Simplemente, yo diría que la adaptación es imposible. Es sobre todo en C, pero la mayoría
la gente no llamaría a lo que escribo C. Utiliza todas las funciones imaginables
de los 386 que pude encontrar, ya que también fue un proyecto que me enseñan acerca de la
386. Como ya se mencionó, se utiliza una MMU, tanto para la paginación (no en el disco
todavía) y la segmentación. Es la segmentación que hace que sea realmente 386
dependiente (cada tarea tiene un segmento de 64 Mb para el código y datos - max 64 tareas
en 4Gb. Cualquier persona que necesita algo más que 64Mb/task - galletas duras).
También utiliza todas las características de gcc que pude encontrar, en concreto el __asm__
Directiva, de forma que no se necesitan objetos de montaje tanto del lenguaje.
Algunos de mis "C" en los archivos (en concreto mm.c) son casi como ensamblador de lo
C. Sería "interesante" incluso para transportarlo a otro compilador (aunque
por qué alguien querría usar otra cosa que gcc es un misterio).
A diferencia de minix, yo también les guste interrupciones, por lo que las interrupciones son
manejado sin tratar de ocultar la razón detrás de ellos (me gusta especialmente
mi disco duro-conductor. ¿Alguien más que interrumpe una unidad de estado
máquina?). Con todo es una pesadilla cargadores.
> En cuanto a las características, pues bien, pseudo ttys, sockets BSD, en modo de usuario
> Sistemas de archivo (lo que puedo decir cat / dev / tcp / kruuna.helsinki.fi / dedo),
tamaño de la ventana> de la estructura tty, llamadas al sistema capaz de soportar
> POSIX.1. Ah, y los nombres largos de archivo de tipo BSD.

La mayoría de estos parece posible (la estructura tty ya tiene recibos de
tamaño de la ventana), excepto quizás por los sistemas de archivos en modo de usuario. En cuanto a POSIX,
Me encantaría tenerlo, pero posix quiere dinero para sus documentos, por lo que
eso no es actualmente una opción. En cualquier caso estas son cosas que no
contar con el apoyo de algún tiempo (primero lo voy a hacer una simple minix-
lookalike, palabra clave simple).
                Linus (Torva...@ kruuna.helsinki.fi)
PS. Para hacer las cosas bien claro - si puedo correr gcc en ella, y bash, y
la mayor parte de la caja [gnu / Utilidades], pero no es muy depurado, y la
la colección es realmente mínima. Ni siquiera el apoyo disco flexible todavía. Lo
no estará listo para su distribución durante un par de meses. Incluso entonces
probablemente no será capaz de hacer mucho más de minix, y mucho menos en algunos
los aspectos. Será libre, aunque (probablemente bajo Licencia GNU o similar).

j...@ cs.HUT.FI (Jyrki Kuoppala) escribe:
> En el artículo <1991Aug25.205708.9...@ klaava.Helsinki.FI>, Torvalds @ klaava (Linus Torvalds Benedicto) escribe:
>> Esto implica que tendré algo práctico dentro de unos meses, y
>> Me gustaría saber qué características más gente quiere. Cualquier sugerencia
>> Son bienvenidos, pero no voy a prometer voy a ponerlas en práctica :-)
> En cuanto a las características, pues bien, pseudo ttys, sockets BSD, en modo de usuario
> Sistemas de archivo (lo que puedo decir cat / dev / tcp / kruuna.helsinki.fi / dedo),
tamaño de la ventana> de la estructura tty, llamadas al sistema capaz de soportar
> POSIX.1. Ah, y los nombres largos de archivo de tipo BSD.

En un nivel inferior:
No me gusta el mecanismo chmem de Minix. Los procesos deben comenzar con
un tamaño mínimo y crecer, ya que necesitan hasta que se agoten de RAM o
espacio en disco. Paginación en el disco sería bueno, también.
Si su sistema operativo es mensaje basado Me gustaría tener arbitrariamente grande
mensajes. Podrían aplicarse eficazmente mediante la asignación de las páginas
en el espacio de direcciones de los receptores (o simplemente pasar un puntero en 68k
sistemas sin MMU). Oh, sí, y el esquema de direcciones para los mensajes
debe ser diferente que en Minix. Los mensajes no deben ser enviados a
números de proceso de ranura, pero a los puertos. De esta forma, los procesos de usuario puede utilizar
mensajes, también, y es más fácil de añadir sus propios servidores.
PS: Estoy muy interesado en este sistema operativo. Ya he pensado en escribir
mi propio sistema operativo, pero decidí que no tendría el tiempo para escribir de todo, desde
cero. Pero supongo que podría encontrar el tiempo para ayudar a criar a un bebé
OS :-)
-
| _ Peter | J. | Holzer Piense en ello |
| |_|_) | Universidad Técnica de Viena | como | evolución
| | | | Departamento de Sistemas en Tiempo Real | en acción! |
| __ / | H...@ vmars.tuwien.ac.at | Tony Rand |


> A diferencia de minix, yo también les guste interrupciones, por lo que las interrupciones son
> Manejado sin tratar de ocultar la razón detrás de ellos (me gusta especialmente
> Mi disco duro-conductor. ¿Alguien más que interrumpe una unidad de estado
máquina>?).

Claro que sí. Para un ejemplo, Mach Alessandro Forin los controladores de adaptador SCSI
por escrito de esta manera. Un comentario de su código:
/ *
 * Esta capa trabajos basados en scripts simples pequeñas "que se instalan
 * En el inicio de la unidad de mando y el chip de su recorrido.
 * La idea viene de las especificaciones de la secuencia de comandos de NCR 53C700 "del procesador.
 *
 * Hay varias razones para esto, sobre todo
 * - La ejecución: identificar los comunes (con éxito) el camino, y lo siguen;
 * En el momento de interrumpir ningún código es necesario para ver el estado actual
 * - El tamaño del código: debe ser fácil para compactar operaciones comunes
 * - Adaptabilidad: el esqueleto de código debe adaptarse a los diferentes chips sin
 * Terribles complicaciones.
 * - Manejo de errores: y es fácil de modificar las acciones realizadas
 * Según las secuencias de comandos para hacer frente a secuencias de extraño, pero bien identificados
 *
 * /
Una manera interesante de escribir un controlador de dispositivo. Creo que esta es una muy vieja
técnica, también.
Buena suerte en tu proyecto OS, suena como un montón de diversión.
Jaime
.................................................. .........................
: Dominio: j...@ cs.umd.edu James da Silva
: Ruta de acceso: uunet! Mimsy! Jds Diseño, desarollo y Grupo de Análisis


Una de las cosas que realmente me molesta acerca de Minix es la manera de los controladores de dispositivo
tiene que ser compilado en el núcleo. Así pues, cómo en hacer algo sensato
código de controlador de dispositivo instalable (Igual va para siempre minix 2,0).
-
Adán David.
(Ad...@ rhi.hi.is)


En el artículo <1991Aug26.110602.19...@ klaava.Helsinki.FI> Torva...@ klaava.Helsinki.FI (Linus Torvalds Benedicto) escribe:
> Aún) y la segmentación. Es la segmentación que hace que sea realmente 386
> Dependiente (cada tarea tiene un segmento de 64 Mb para el código y datos - max 64 tareas
> En 4Gb. Cualquier persona que necesita algo más que 64Mb/task - galletas duras).

¿Es eso max 64 64Mb tareas o máximo 64 tareas independientemente de su tamaño?
-
  Alan Barclay
  iT | E-mail: uno...ukpoit.uucp @
  Barker Lane | BANG-STYLE: ukc .....!! Ukpoit! Alan
  CHESTERFIELD S40 1DY | VOZ: +44 246 214 241


En el artículo <1991Aug27.143432.10...@ ukpoit.co.uk a>...@ ukpoit.co.uk (Alan Barclay) escribe:
> En el artículo <1991Aug26.110602.19...@ klaava.Helsinki.FI> Torva...@ klaava.Helsinki.FI (Linus Torvalds Benedicto) escribe:
>> Aún) y la segmentación. Es la segmentación que hace que sea realmente 386
>> Dependiente (cada tarea tiene un segmento de 64 Mb para el código y datos - max 64 tareas
>> En 4Gb. Cualquier persona que necesita algo más que 64Mb/task - galletas duras).
> ¿Es max 64 64Mb tareas o máximo 64 tareas independientemente de su tamaño?


Me temo que es de 64 max tareas (y se utiliza como un intercambiador), no importa
por pequeño que deberían ser. La fragmentación es el mal - así es como se
manipulados. Dado que la opinión actual parece ser que el 64 Mb es más que
suficiente, pero 64 tareas podría ser un poco lleno de gente, probablemente voy a cambiar el
límites se pueden cambiar fácilmente (para 32Mb/128 tareas, por ejemplo) con sólo una
recompilación del kernel. No quiero estar en la máquina cuando
alguien está generando> 64 procesos, aunque :-)
                Linus