Archive for Sistemas operativos
August 2, 2008 at 13:19 · Filed under Linux, Vision artificial
Michel Xhaard hace algún tiempo se hizo famoso por haber escrito los drivers para Linux para más de 200 webcams.
Michel, que tiene algo más de 60 años, es un médico francés que está especializado en procesar imágenes de ultrasonidos. En cuestión de cuatro años fue capaz de desarrollar drivers para múltiples webcams, inicialmente empezó para el chipset Sunplus SPCA y ahora cubre muchos más, principalmente a base de reutilizar el código de unos drivers en otros.
Las cámaras con los chipsets soportados por la familia SPCA son de múltiples fabricantes y modelos.
El caso de Michel no es el único caso de un médico que tiene como pasatiempos la informática: Con Kolivas es anestesista y ha hecho importantes desarrollos para el kernel de Linux.
August 2, 2008 at 12:36 · Filed under Linux, Vision artificial
El soporte para webcams en Linux es una de las materias que aún quedan pendientes para que Linux esté tan cerca del usuario doméstico como lo están Windows o MacOS X.
Philips destaca por fabricar buenas cámaras con buenos sensores, siendo uno de los proveedores de Logitech — así que al comprar Logitech realmente gran parte de las piezas importantes son Philips en muchos modelos (que no en todos). Hasta la fecha en Linux gran parte de las cámaras Philips estaban soportadas por el driver PWC. Este driver tiene dos partes, el PWC propiamente dicho, que es código abierto y está dentro del kernel, y el PWCX que es una parte binaria que opera fuera del kernel (obviamente, por temas de licencia) e interactúa con el PWC a través de un hook.
El código del PWCX es algo que Philips quiere mantener escondido, por lo que al desarrollador inicial del PWC (Nemosoft Unv) Philips le obligó a firmar un NDA (Non-Disclosure Agreement) con caducidad a los tres años –ya vencidos, aunque aún no ha desvelado nada. La inclusión de esta parte binaria es lo que hizo que el equipo del kernel Linux se empeñara en no incluir el PWC como parte del kernel, por lo que Nemosoft Unv al final decidió dejar el desarrollo. En definitiva, este código lo que permitía era hacer una descompresión del flujo de datos recibido para así poder trabajar con resoluciones altas (640×480).
Actualmente Luc Saillard ha retomado el desarrollo principalmente para el kernel 2.6, y permite hacer esa descompresión para gran resolución sin necesidad de parte binaria.
June 3, 2008 at 22:04 · Filed under Sistemas operativos
Teniendo que hacer un
mplayer -vo xv -ao alsa /descargas/Temp/014.part
resulta que hice un
rm /descargas/Temp/014.part
y como en la consola no hay papelera de reciclaje, pues… ¡cucú!
Así que me puse a buscar como loco y al final encontré este documento.
Hay que remarcar que tal fichero estaba abierto por el aMule mientras ocurría todo esto, y ha sido gracias a eso que lo he podido recuperar.
Abreviando, el método consiste en buscar qué PID tiene el programa que está tirando del fichero:
pablo@golgi:~$ ps aux | grep amule | grep -v grep
pablo 4165 1.6 3.6 114592 37976 ? Sl May25 214:10 amule
Y a continuación ir a su correspondiente entrada en /proc. Si el PID es el 4165, su entrada será /proc/4165/, y en /proc/4165/fd/ tendremos enlaces a los descriptores de fichero abiertos.
Con lsof +L1 podemos ver qué inodos carecen de referencias, y además qué descriptor de fichero tienen (si hay alguno). En este caso la columna correspondiente de la salida de lsof nos dice que tiene el descriptor 11, ¡¡así que en /proc/4165/fd/11 tenemos el fichero!! Ahora hacemos…
cp /proc/4165/fd/11 /descargas/Temp/014.part
Y todo como si nada (por cierto, el sistema de ficheros era ext3, pero eso debería de dar igual).
Ahora la explicación larga:
La información en el disco duro se almacena en sectores, y cada sector se identifica secuencialmente por un número.
Si queremos guardar un fichero, el sistema operativo busca una serie de sectores libres donde quepa el fichero y a continuación creará un inodo y copia el contenido del fichero a esos sectores libres. Ese inodo (nodo índice) es un índice de qué sectores ocupa el fichero, además de guardar qué permisos tiene el fichero, tamaño, tipo de fichero (enlace duro, enlace simbólico, fichero normal, directorio, etc.), propietarios, etc. Otro de los datos que guarda es un contador de referencias.
Un directorio es un fichero que guarda los nombres de los ficheros que hay dentro suyo y una referencia a sus respectivos inodos.
Cuando borramos un fichero lo primero que se hace es desvincular el nombre del fichero del inodo, es decir, borrar la entrada correspondiente del fichero de directorio. Así nadie podrá acceder a ese fichero, ya que cuando hacemos referencia al nombre del fichero, éste no aparece en el fichero de directorio. Además de borrar el nombre se disminuye en uno el contador de referencias del inodo.
Sin embargo, no sólo hay que desvincular el nombre, si no que también hay que borrar el inodo. Mientras el fichero está siendo usado por algún proceso el inodo permanecerá ahí, pero en el momento en que ese proceso cierre el fichero, el sistema operativo borrará el inodo por tener a cero el contador de referencias, y además todos los sectores usados por el contenido del fichero los marcará como libres.
En el caso anterior al haber hecho un rm teníamos el nombre desvinculado, pero como el proceso amule estaba tirando del fichero aún teníamos el inodo en disco y los sectores del fichero intactos.
Gracias a /proc y lsof pude localizar el descriptor de fichero que se refería a ese inodo, y al copiarlo lo que se hace es meterlo en sectores nuevos, indexados por un nuevo inodo, que tendrá su propia entrada en el fichero del directorio /descargas/Temp/ (i.e., un nombre).
Otra de las opciones que traté de hacer era, mediante debugfs, tratar de crear una entrada en el fichero de directorio hacia ese inodo, pero no conseguí que tragara con el número de inodo que le di (y que saqué mediante lsof)
December 15, 2007 at 16:50 · Filed under Sistemas operativos
Un spinlock es un mecanismo para controlar bloqueos. Quien haya echado un vistazo al código fuente del kernel Linux lo habrá visto sin tener que profundizar mucho.
Básicamente es un procedimiento que, mediante espera ocupada, permanece inactivo hasta que se libera el bloqueo, en cuyo caso pasa a tomarlo.
Realmente es la forma más sencilla de acceder a un bloqueo, con el único inconveniente de que está consumiendo CPU a cambio de no hacer nada más que esperar:
mientras haya bloqueo {
repetir
}
adquiere bloqueo
Lo extraño aquí es que se utilice espera ocupada, ya que siempre se trata de evitar este método. La idea es que los spinlocks van a ser muy breves, la espera ocupada va a ser tan breve y fugaz, que sería muy laborioso para el procesador y el sistema operativo andarse con procedimientos más avanzados. No merecería la pena por unos pocos nanosegundos de espera ocupada andar montando todo un circo con semáforos, o señales o algún otro mecanismo para sincronismo.
Desde luego, si van a ser más de unos nanosegundos no es nada recomendable que los hilos pierdan su cuota de tiempo de proceso iterando sin hacer nada productivo.
Otro problema potencial es que desde que se sale del bucle hasta que se apropia del bloqueo puede surgir una condición de carrera. Para evitar los problemas que ello acarrea se usarán instrucciones atómicas en ensamblador que comprueben el bloqueo y lo adquieran, pero obviamente, esto requiere soporte por parte de la arquitectura. Por supuesto, hay más soluciones, como el algoritmo de Peterson y el de Dekker.
Bibliografía:
- Entrada en la Wikipedia EN
- El fichero /Documentation/spinlocks.txt en el código fuente de Linux contiene información acerca de los spinlocks y su implementación en el kernel linux.
October 28, 2007 at 20:28 · Filed under Linux, Sistemas operativos
Hace un mes salía en barrapunto una noticia acerca del tamaño óptimo para la swap en linux, y tras dedicarle algo de tiempo las conclusiones que he sacado vienen siendo que swap hay que usar la justa :D.
Ni tiene sentido usar demasiada, ya que con las cantidades de RAM que hay hoy en día no llega a emplearse, ni se debe eliminar, ya que es necesaria para agilizar la localización de fragmentos libres para nuevos malloc()s.
Otro método que se utiliza para agilizar la reserva de memoria es eliminar comprobaciones, llegando incluso a ceder más memoria a los programas de la que realmente hay libre. Simplemente a un malloc() se responde de forma afirmativa, y es sólo a la hora de escribir por primera vez cuando se localiza el espacio de memoria reservado. Esta política es proclive a producir algún que otro problema de vez en cuando ante un Out of Memory (OOM), y esa es precisamente la ocupación del OOM killer, la de resolver estos problemas no muy frecuentes de la forma más rápida posible: eligiendo un proceso y matándolo.
Normalmente en un entorno de escritorio, a excepción de ciertas aplicaciones que consumen cantidades desorbitadas de memoria por mal funcionamiento (p.ej. firefox) o por que son así (eclipse, aplicaciones de cálculo, etc.), las necesidades de swap no son en absoluto grandes, y normalmente con la RAM que se instala actualmente en los ordenadores (medio o un giga) suele ser maś que suficiente.
No obstante, la swap no es totalmente prescindible. Los procesos dormidos (los que esperan alguna señal o evento) normalmente son enviados a swap con la finalidad de liberar memoria principal que pueda ser usada como buffer de disco. Así mismo, la swap también ayuda a encontrar rápidamente un hueco libre para las aplicaciones que soliciten un espacio de memoria (malloc()s y calloc()s) pese a la fragmentación que pueda haber.
El único caso donde se podría requerir un buen espacio de swap es en el caso de querer suspender el sistema, para lo que linux copia íntegramente el contenido de la memoria principal al swap, en cuyo caso el swap debe tener capacidad suficiente para copiar toda la RAM y además mantener lo que estuviera ya guardado en el swap. La política que sigue Windows para esto es ligeramente diferente, ya que se copia al sistema de ficheros, y no al swap.
Windows de hecho utiliza como espacio de intercambio un fichero de tamaño variable contenido sobre el sistema de ficheros raíz. Este enfoque, igualmente válido en Linux, no está muy popularizado a pesar de no haber mayor penalización de velocidad.
Contrariamente a lo que se podría pensar la conversión de dirección virtual a bloque de disco es inmediata, ya que al realizar el swapon se hace una tabla de equivalencias que cubre y agiliza todas estas conversiones sin necesidad de apoyo por parte del driver del sistema de ficheros.
La única restricción es que el fichero debe crearse en la infancia del sistema de ficheros, para evitar que esté muy fragmentado, ya que el kernel puede rechazarlo como swap.
Igualmente, el fichero es de tamaño estático, y no dinámico como suele ocurrir en Windows
Otra opción totalmente experimental consiste en utilizar parte de la memoria de al tarjeta de vídeo, en vez del disco duro, como espacio de intercambio.
« Previous entries ·
Next entries »
