Al instalar sistemas operativos adicionales a los que tenemos generalmente nos dan la opción de instalar un boot loader en el MBR. Esto sobre escribe nuestro anterior boot loader (GRUB o Lilo en la mayoría de los casos), así que es preferible no tocar el MBR.

En este pequeño tip les mostraré cómo configurar GRUB para iniciar aquel hermoso sistema FreeBSD que acabas de instalar junto a tu Linux. La verdad es muy sencillo, lo único que debes hacer es añadir lo siguiente al archivo /boot/grub/menu.lst:

Una breve explicación:

• title FreeBSD 8.0 : Crea un nuevo ítem en el menú y le pone el título ‘FreeBSD 8.0′ (en realidad puedes colocar lo que quieras).
• root (hd0,a) : Seleccionamos la partición raíz donde se encuentra FreeBSD. En el ejemplo hd0 es el primer disco duro (hda en Linux). En GRUB hda es hd0. Así, por ejemplo, hda2 (segunda partición del primer disco) es hd0,1 en Grub. Además, recuerda que FreeBSD usa nombres del tipo a, b, c para representar los nombres de las particiones. Si tuvieras instalado FreeBSD en la tercera partición entonces tendrías que usar: root (hd0,2,a)
• kernel /boot/loader : Se usa para cargar la imagen de boot principal. FreeBSD usa /boot/loader para cargar el resto del kernel y OS.

Actualización: entrada para GRUB2

Si estás usando GRUB2 entonces deberás modificar tu archivo /boot/grub/grub.cfg y añadir esto:

Fuente: Lista de correo FreeBSD | Foros FreeBSD

Seam es un proyecto desarrollado por JBoss, cuyo lider es Gavin King. Es un completo framework para la creación de aplicaciones web 2.0 que unifica varias tecnologías como AJAX, Enterprise Java Beans (EJB3), Java Server Faces (JSF), Java Portlets and Business Process Management (BPM), Hibernate, y mucho más.

De la Wikipedia:

Seam introduce el concepto de contextos. Cada componente de Seam existe dentro de un contexto. El contexto conversacional por ejemplo captura todas las acciones del usuario hasta que éste sale del sistema o cierra el navegador – inclusive puede llevar un control de múltiples pestañas y mantiene un comportamiento consistente cuando se usa el botón de regresar de el navegador.

Tú puedes automáticamente generar una aplicación web de altas, bajas, cambio y modificaciones a partir de una base de datos existente utilizando una herramienta de linea de comandos llamada seam-gen incluida con el framework.

El desarrollo WYSIWYG es facilitado a través del uso de las JBoss Tools, que es un conjunto de plug-ins diseñados para el entorno integrado de desarrollo Eclipse. Seam puede ser integrado con las bibliotecas de componentes JSF JBoss RichFaces o con ICEsoft ICEFaces. Ambas bibliotecas poseen soporte para AJAX.

Actualmente soporta varios contenedores de aplicaciones como JBoss 4 o 5, IBM Websphere, BEA WebLogic, Oracle OC4J y por supuesto Apache Tomcat.

Puedes encontrar ejemplos de proyectos creados con seam y listos para ejecutar dentro del directorio examples de la aplicación.

Referencias y documentación:

• Página oficial de Seam Framework
• Página del producto JBoss Seam
• Documentación Online mantenida por la comunidad
• Documentación de JBoss Seam
• Introduction to JBoss Seam [artículo en InfoQ]

Laboratorio de JBoss Seam Framework

Con el siguiente laboratorio se pretende dar un punto de partida a la creación de aplicaciones usando Seam. El laboratorio está enfocado al desarrollo sobre Eclipse, que es el IDE que recomiendo para trabajar con Seam.

Este laboratorio está enfocado al uso de Seam para JBoss, aunque con pocas o sin modificaciones puede funcionar en Apache Tomcat. Recordemos además que Seam también soporta los contenedores IBM Websphere, BEA WebLogic y Oracle OC4J.

Nota: todas las pruebas se realizaron sobre Linux (Gentoo amd64) y OpenSolaris 9.6. Sin embargo, hacerlo en Windows con los mismos pasos no debería presentar problemas; solo se debe tener cuidado con las rutas donde se guarden los archivos usados.

Prerequisitos

• Eclipse 3.4 o 3.5
• La última versión de JBoss Seam (la más reciente al momento de escribir este documento es la 2.2.0).
• La última versión de Jboss Server (la más reciente al momento de escribir este documento es la 5.1.0).
• Un gestor de bases de datos. En mi caso he usado MySQL, aunque hay soporte para muchos otros gestores. No olvides además descargar el conector JDBC, en mi caso el mysql-connector-java-bin.jar.

Instalación

Para instalar Seam y JBoss basta con descomprimir los paquetes que descarguemos de Internet. Yo recomiendo hacerlo en la carpeta /opt en sistemas UNIX/Linux, o directamente en C:/ en sistemas Windows.

Creación de un proyecto base para Eclipse

SeamFramework nos proporciona una herramienta de línea de comandos para la generación de proyectos base. Vamos al directorio donde lo instalamos y ejecutamos:

Ahora debemos responder a cada una de las preguntas que nos hace; muchas de ellas las debemos dejar por defecto, así que nos concentraremos solo en aquellas en donde tengamos que cambiar. Resumiendo:

• El directorio donde se creará el proyecto:
  [input] Enter the directory where you want the project to be created (should not contain spaces) [/home/funtoo/projects] [/home/funtoo/projects]
  /home/funtoo/Poli/Componentes/seam-framework/workspace
• El directorio donde se encuentra el JBoss AS:
  [input] Enter your JBoss AS home directory [C:/Program Files/jboss-5.1.0.GA] [C:/Program Files/jboss-5.1.0.GA]
  /opt/jboss-5.1.0.GA/
• El nombre del proyecto:
  [input] Enter the project name [myproject] [myproject]
  holaseam
• Vamos a desarrollar nuestra aplicación como EAR:
  [input] Is this project deployed as an EAR (with EJB components) or a WAR (with no EJB support)? [war] (ear, [war])
  ear
• Definimos el nombre del paquete en base de la aplicación:
  [input] Enter the base package name for your Java classes [com.mydomain.holaseam] [com.mydomain.holaseam]
  org.ejemplo.seam
• Los que hacen referencia a los Session Beans o Test Cases los podemos dejar como nos lo pongan. El gestor de base de datos; en este caso usé mysql aunque debería ser practicamente transparente:
  [input] What kind of database are you using? [hsql] ([hsql], mysql, derby, oracle, postgres, mssql, db2, sybase, enterprisedb, h2)
  mysql
• Ingresamos la ruta en donde se encuentra el driver JDBC:
  [input] Enter the filesystem path to the JDBC driver jar [] []
  /opt/conectores/mysql-connector-java-5.0.8-bin.jar
• Ahora debemos definir la URL de conexión a la base de datos. En este caso, he creado una base de datos llamada ejemplo, y por lo tanto la URL quedaría así:
  [input] Enter the JDBC URL for your database [jdbc:mysql:///test] [jdbc:mysql:///test]
  jdbc:mysql://localhost:3306/ejemplo
• Con esta opción se ejecutará un script llamado import.sql cada vez que hagamos un deploy del proyecto. Dicho archivo deberá tener los scripts necesarios para crear tablas y registros. Puesto que en este laboratorio poco vamos a usar MySQL, puedes poner lo que quieras; pero es importante tener en cuenta esta opción a la hora de desarrollar un proyecto.
  [input] Do you want to recreate the database tables and execute import.sql each time you deploy? [n] (y, [n])
  y

Ya que hemos configurado lo que será el proyecto, es hora de crearlo. Ejecutamos el comando:

Esto creará un proyecto base que puedes abrir con Eclipse, y eso es justo lo que haremos a continuación.

Abrimos eclipse y nos aseguramos que el workspace sea el mismo directorio en el que creamos el proyecto desde Seam. Vamos a la creación de un nuevo proyecto Java:

Le damos el mismo nombre que a nuestra aplicación Seam (en este caso holaseam):

Y puesto que ya existe un proyecto creado en el workspace muchas de las opciones ya aparecen asignadas. Hacemos clic en Next y vemos que ya hay una estructura de directorios creada con la base del proyecto Seam.

Hacemos clic en Finish, y ya podemos comenzar a editar y modificar el proyecto.

Despliegue del proyecto

Primero debemos iniciar el servicio de JBoss. Para ello ejecutamos el archivo run.sh (run.bat en Windows) del directorio bin de Jboss. Este dejará el servicio web corriendo por defecto en el puerto 8080.

Para hacer el despliegue sobre JBoss, usamos un archivo Ant que se generó junto con el proyecto. Dicho archivo nos permite ejecutar tests, hacer (re)despliegues, generar el JavaDoc, entre otras. Así que habrímos el archivo build.xml y nos aseguramos que la vista Outline esté abierta:

Dentro de la vista Outline podemos ver los componentes del archivo build.xml y podemos ejecutarlos con Ant. En este caso, buscamos el componente deploy, hacemos clic derecho, Run As, y Ant Build.

Algunas veces se generan errores al hacer el despliegue:

Si es tu caso, deberás eliminar los archivos y directorios que tengan el nombre del proyecto del directorio deploy en JBoss. En mi caso los elimino con este comando:

Si todo sale bien, cuando hagamos de nuevo deploy veremos algo como esto:

Es hora de probar la aplicación. Abrimos el navegador en la dirección: http://localhost:8080/holaseam/

Descargar versión en PDF

Descargar

Esta guía es la continuación de la anterior entrada, en donde explicaba cómo montar un servidor Git. Ahora veremos las operaciones básicas sobre el repositorio (hacer un checkout, añadir o borrar objetos, commit, etc.). Del lado del cliente también debemos tener instalado git:

En Debian:

En Gentoo:

Clonar el repositorio

Llamamos “clonar” a descargar los archivos fuentes de un repositorio git a un nuevo directorio. En este caso usaremos el método que usa SSH y el usuario que creamos en la entrada anterior.

Los archivos los añadimos normalmente, es decir, editándolos dentro del directorio del proyecto o copiándolos de otro lado. Por ejemplo:

Añadir archivos al repositorio

Antes de comenzar a añadir cosas o realizar cambios debemos actualizar el repositorio con respecto al del servidor:

Ahora añadiremos los archivos que hemos creado al repositorio:

o mejor aún:

Subir cambios al servidor local

Para subir los cambios hechos al servidor local (lease el comentario de CaStarCo):

Para subir los cambios al repositorio debemos ejecutar este comando:

Ver cambios entre versiones

Para ver los cambios entre la versión que tenías antes de hacer un git pull y la actual, puedes ejecutar el comando:

O puedes ver todos los cambios que ha sufrido el proyecto usando:

Puedes también consultar la guía oficial de Git para cosas más avanzadas.

¡Hola a todos! Ya que me encuentro haciendo un proyecto para la Universidad, he decidido esta vez probar Git y dejar a un lado mi querido Subversion. Git es básicamente un sistema de control de versiones, creado por Linus Torvalds, y es usado en proyectos grandes como el Kernel de Linux. Así que he preparado una pequeña guía de instalación y configuración de Git, además de la interfaz web del mismo, lo cual nos permite ver los cambios del proyecto de una manera más amena.

Para este mini proyecto he instalado el servidor en una máquina virtual corriendo Debian 5. El motivo de dejar mi Gentoo por un rato es porque ya es de madrugada y necesitaba que la instalación fuera más rápida; además no me gusta instalar cosas que más adelante no necesitaré: para eso está la virtualización. ¡Basta de rodeos, vamos al grano!

Instalando los paquetes necesarios

Instalaremos Apache2, la base de git y los módulos web de git (y el server de ssh para que los clientes se conecten):

Ahora creamos los directorios /var/cache/git (el repositorio git) y /var/www/git para el gitweb.cgi:

En nuestro ejemplo, el directorio raiz del apache es /var/www; ahora debemos crear un archivo de configuración de Apache para el git:

Ponemos lo siguiente adentro:

<Directory /var/www/git>
   Allow from all
   AllowOverride all
   Order allow,deny
   Options ExecCGI
   <Files gitweb.cgi>
   SetHandler cgi-script
   </Files>
</Directory>
DirectoryIndex gitweb.cgi
SetEnv  GITWEB_CONFIG  /etc/gitweb.conf

Ahora movemos los archivos gitweb.cgi, .png y .css de git a /var/www/git:

Debemos ahora hacer un par de cambios en el archivo /etc/gitweb.conf debido a los archivos que movimos:

$projectroot = '/var/cache/git/';
$git_temp = "/tmp";
#$home_link = $my_uri || "/";
$home_text = "indextext.html";
$projects_list = $projectroot;
$stylesheet = "/git/gitweb.css";
$logo = "/git/git-logo.png";
$favicon = "/git/git-favicon.png";

Recargamos la configuración del apache:

Iniciando un proyecto en Git

Creamos la carpeta del proyecto…

Iniciamos un repositorio para nuestro nuevo proyecto y lo configuramos de acuerdo a nuestras necesidades:

Para marcar un repositorio como exportado se usa el archivo git-daemon-export-ok:

Para iniciar el servicio de Git que ejecuta un servidor para hacer público nuestro repositorio, ejecutamos el siguiente comando (no debe haber un slash después de la ruta del repositorio):

Ahora el repositorio se encuentra corriendo en el puerto 9418 de nuestro computador. Por último, le daremos permisos de escritura a un usuario que no sea root, de tal manera que con dicho usuario se puedan hacer cambios remotos en el repositorio:

Acceder al repositorio

Para descargar el repositorio de la manera convencional, basta con ejecutar el comando:

O lo puedes acceder vía web; en mi caso el servidor está en la dirección 192.168.0.5, entonces basta con visitar http://192.168.0.5/git/:

Fuentes y enlaces interesantes

• Página oficial del proyecto
• Artículo guía de esta entrada
• Miniguia de Git

Antes que nada, una definición de prompt:

Se llama prompt al carácter o conjunto de caracteres que se muestran en una línea de comandos para indicar que está a la espera de órdenes. Éste puede variar dependiendo del intérprete de comandos y suele ser configurable (extraído de la Wikipedia).

Normalmente no lo vemos como algo muy importante, pero leyendo este artículo en Make Tech Easier he reflexionado un poco acerca de este aspecto, y he hecho un listado de los prompts que me parecieron más útiles:

1. Cambiar el color del prompt dependiendo del resultado del comando ejecutado

Este es de los que más me ha gustado: si ejecutas bien un comando, el prompt queda en su color original (en este caso verde); pero si te equivocas al tipearlo entonces queda en rojo. Además tiene una característica bastante interesante: te muestra el número dentro del historial que será asignado al comando que ejecutes. El resultado es el siguiente:

Para usarlo, ejecutas esto o lo pones en tu archivo ~/.bashrc para hacerlo permanente:

PROMPT_COMMAND='PS1="\[\033[0;33m\][\!]\`if [[ \$? = "0" ]]; then echo "\\[\\033[1\\\;32m\\]"; else echo "\\[\\033[1\\\;31m\\]"; fi\`[\u:\`if [[ `pwd|wc -c|tr -d " "` > 18 ]]; then echo "\\W"; else echo "\\w"; fi\`]\$\[\033[0m\] "; echo -ne "\033]0;`hostname -s`:`pwd`\007"'

2. Mostrar una carita feliz si se ejecuta un comando correctamente

Este puede sonar algo infantil pero me parece bastante interesante. Funciona igual que el de arriba y el resultado es el siguiente:

PS1="\`if [ \$? = 0 ]; then echo \[\e[33m\]^_^\[\e[0m\]; else echo \[\e[31m\]O_O\[\e[0m\]; fi\` \[\033[01;32m\]\u:\[\033[01;34m\]\w \$\[\033[00m\] "

3. Mostrar bastante información en el prompt

El siguiente prompt es bastante grande y se encuentra distribuido en 3 líneas. Muestra la fecha y hora actual, el usuario, el nombre del equipo, la terminal con la que se está trabajando, el directorio en donde estamos, la cantidad de archivos en el directorio y el espacio que ocupan. Se ve así:

PS1="\n\[\033[35m\]\$(/bin/date)\n\[\033[32m\]\w\n\[\033[1;31m\]\u@\h: \[\033[1;34m\]\$(/usr/bin/tty | /bin/sed -e 's:/dev/::'): \[\033[1;36m\]\$(/bin/ls -1 | /usr/bin/wc -l | /bin/sed 's: ::g') files \[\033[1;33m\]\$(/bin/ls -lah | /bin/grep -m 1 total | /bin/sed 's/total //')b\[\033[0m\] $ \[\033[0m\]"

4. Mostrar la cantidad de procesos corriendo en background

Este es otro bastante interesante ya que te muestra aparte de lo normal: el número en el historial del comando a ejecutar, y la cantidad de procesos que se encuentren corriendo en background (aquellos ejecutados de la forma comando &). Se ve así:

PS1='\[\e[1;32m\]\u@\H:\[\e[m\] \[\e[1;37m\]\w\[\e[m\]\n\[\e[1;33m\]hist:\! \[\e[0;33m\] \[\e[1;31m\]jobs:\j \$\[\e[m\] '

5. Mostrar información de los archivos y procesos en background

Esta combina cosas de la 3 y la 4: muestra cantidad de archivos y espacio que ocupan, además de la cantidad de procesos corriendo en background. El resultado es este:

PS1="\n\[\e[30;1m\]\[\016\]\[\017\](\[\e[34;1m\]\u@\h\[\e[30;1m\])-(\[\e[34;1m\]\j\[\e[30;1m\])-(\[\e[34;1m\]\@ \d\[\e[30;1m\])->\[\e[30;1m\]\n\[\016\]\[\017\](\[\e[32;1m\]\w\[\e[30;1m\])-(\[\e[32;1m\]\$(/bin/ls -1 | /usr/bin/wc -l | /bin/sed 's: ::g') files, \$(/bin/ls -lah | /bin/grep -m 1 total | /bin/sed 's/total //')b\[\e[30;1m\])--> \[\e[0m\]"

¿se te ocurre algún otro?

Actualización: he creado un ZIP con los prompts dentro ya que hay usuarios que, por culpa del navegador, no pueden verlos completos (cosas del resaltador de sintaxis):

Descargar

Esta entrada pretende profundizar los temas aprendidos en el anterior artículo (Tu primer módulo cargable para el Linux kernel), con el fin de clarificar dudas, atar algunos cabos que dejamos sueltos y prepararnos para los siguientes artículos.

¿Puedo usar directamente el árbol del código fuente del kernel?

Sí, por supuesto. Como ya sabes, no es posible compilar un módulo cargable sin al menos parte del código fuente del kernel – esto es, la parte que contiene la infraestructura de construcción general y los archivos de cabecera esenciales. Solo por recordar, un archivo header (con extensión .h), contiene, normalmente, una declaración directa de clases, subrutinas, variables, u otros identificadores; sin la definición de estas, no es posible compilar código que las use.

En cualquier caso, es siempre útil tener una copia completa del código del kernel, y la manera más fácil de obtenerla es usando git:

Además que puedes actualizarlo fácilmente:

Nótese que, al contrario de instalar el paquete oficial de desarrollo del kernel como hicimos en el anterior artículo, usando git no es necesario tener privilegios administrativos para poner todo el código en algún lugar de tu directorio home. Además, si por alguna razón no puedes usarlo, puedes descargarte un archivo tar y funcionará igual; claro, usar git es mucho más cool

Urgando en el código fuente: examinando los archivos de cabecera (Header Files)

Recordemos que en el ejemplo del artículo anterior, nuestro código contiene referencias a archivos de cabecera del kernel:

#include <linux/module.h>      // para todos los módulos
#include <linux/init.h>        // para entrada y salida de macros
#include <linux/kernel.h>      // para los macros de prioridad de printk
#include <asm/current.h>       // procesar información, solo por diversión
#include <linux/sched.h>       // para usa la estructura task_struct

Tales referencias son siempre relativas al nivel superior del directorio include/ en el código fuente del kernel, así que un include de, por ejemplo, <linux/module.h>, se refiere al archivo de cabecera include/linux/module.h, y así sucecivamente.

Sin embargo, si miras un poco más de cerca, notarás que no hay un directorio include/asm/, lo cual es bastante fácil solucionar. Incluso si no planeas construir algo contra el código fuente que descargaste, deberías prepararlo de tal manera que refleje de una manera más precisa lo que piensas hacer con él:

Los comandos anteriores hacen bastantes cosas, aunque lo único que nos interesa en este momento es que crea algunos enlaces simbólicos en el directorio include/, que reflejan la arquitectura de nuestro sistema.

Antes de ejecutar los comandos:

Después de ejecutarlos:

Una vez que esto es hecho, los includes de preprocesador tendrán sentido, y podemos usar los nombres genéricos para referirnos al archivo de cabecera apropiado de ahora en adelante. Por supuesto, esto que hicimos no es necesario hacerlo con los paquetes oficiales de desarrollo del kernel, puesto que ya vienen preparados.

¿Es posible generar mensajes de salida con un módulo?

No, no lo es. Bueno, no realmente. Como un autor de módulos novato, es necesario que entiendas que tu módulo será ejecutado en el kernel space, no en el user space, así que debes dejar de pensar en impresiones de mensajes en la consola. Olvídate de ello. La manera canónica de generar mensajes de depuración desde tu módulo es con llamadas printk:

printk(KERN_INFO "Hola, el modulo esta siendo cargado.\n");
printk(KERN_INFO "El user space del proceso es '%s'\n", current->comm);
printk(KERN_INFO "El PID es  %i\n", current->pid);  

Corriendo el riesgo de sobre-simplificar el asunto, la salida que genera printk acabará en el archivo /var/log/messages así que, si estás insertando y removiendo tu módulo, es útil tener una terminal aparte mostrando en tiempo real todo lo que sea escrito en dicho archivo (para lo cual necesitas privilegios administrativos):

Para los más ambiciosos, es útil fijarse en la definición de los niveles de log en el archivo de cabecera <linux/kernel.h>:

#define KERN_EMERG    "<0>"  /* system is unusable                 */
#define KERN_ALERT    "<1>"  /* action must be taken immediately   */
#define KERN_CRIT     "<2>"  /* critical conditions                */
#define KERN_ERR      "<3>"  /* error conditions                   */
#define KERN_WARNING  "<4>"  /* warning conditions                 */
#define KERN_NOTICE   "<5>"  /* normal but significant condition   */
#define KERN_INFO     "<6>"  /* informational                      */
#define KERN_DEBUG    "<7>"  /* debug-level messages               */

Si algunos de ellos lucen vagamente familiares, no es de sorprenderse – son los niveles de depuración (debugging) soportados por syslog, así que eres libre de personalizar el syslog si quieres redireccionar la salida de tu módulo a donde quieras basado en los niveles de log, lo cual está más allá del objetivo de este artículo.

printk(KERN_INFO "Hola, el modulo esta siendo cargado.\n");
printk("<6>" "Hola, el modulo esta siendo cargado.\n");
printk("<6>Hola, el modulo esta siendo cargado.\n");

Aun así, es mejor hacerlo como se muestra en la primera línea. Incluso programando cosas del kernel, la estética importa.

Cargando tu módulo lleno de información

Como te diste cuenta la última vez, puedes cargar tu módulo con información bastante útil como:

MODULE_AUTHOR("Robert P. J. Day");
MODULE_AUTHOR("Cristian Castiblanco [solo lo puse en castellano]");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_DESCRIPTION("Aqui puedes poner una descripcion de tu modulo");

que puede examinarse con el comando modinfo:

$ sudo modinfo hola.ko
filename: hola.ko
description: Aqui puedes poner una descripcion de tu modulo
license: Dual BSD/GPL
author: Cristian Castiblanco [solo lo puse en castellano ]
author: Robert P. J. Day
depends:
vermagic: 2.6.29-gentoo-r5 SMP mod_unload CORE2

Algunas cosas útiles acerca de esta característica:

• El conjunto completo de estos macros está definido en el archivo de cabecera <linux/module.h>, en donde verás macros relacionados con firmware, tablas de dispositivos y más.
• Además de esos macros en específico, está el menos conocido macro genérico MODULE_INFO, el cual puedes usar dentro del módulo en el lugar que quieras. Curiosamente, muy pocos programadores toman ventaja de este.
• La única macro que realmente debes poner es la licencia. Si no especificas alguna de las variaciones de la licencia GPL, entonces el módulo “contaminará” el kernel, un tema que trataremos en otro artículo. El conjunto completo de licencias válidas está definido en el mismo archivo de cabecera.

Compilando contra el código fuente del kernel

Finalmente, podrías querer construir tu módulo, no contra el código instalado por el paquete de desarrollo, sino contra el código que descargaste tú mismo. Si ese es tu plan, es bastante simple.

Primero, como decíamos arriba, necesitas preparar tu código fuente para construir el módulo:

Todo lo que falta es configurar el Makefile de tal manera que compile el módulo contra nuestro código fuente. Recordemos parte del archivo Makefile del artículo anterior:

ifeq ($(KERNELRELEASE),)
KERNELDIR ?= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)

Lo que hace la segunda línea es asignar la ubicación del código fuente del kernel a ser usado. Para cambiar esta variable, podemos asignarle el valor deseado con este comando:

y aquí es donde comienzas a notar algunas diferencias. Asumiendo que la versión del código que descargué es 2.6.31-rc1, esto es lo que sucede en mi sistema:

Puesto que estoy compilando contra un código fuente que no concuerda con el que estoy corriendo actualmente, pierdo la tabla de símbolos actual, pero la compilación funciona.

El comando modinfo también muestra el árbol contra el cual el módulo fue compilado:

$ sudo modinfo hola.ko
filename: hola.ko
description: Aqui puedes poner una descripcion de tu modulo
license: Dual BSD/GPL
author: Cristian Castiblanco [solo lo puse en castellano ]
author: Robert P. J. Day
depends:
vermagic: 2.6.31-rc1 SMP mod_unload 686

Ahora algunas preguntas capciosas – ¿es posible cargarlo? ¿no dará problemas por la versión? Eso depende de si el kernel que se está ejecutando fue configurado para permitir diferencias de versiones, y hay una manera rápida de comprobarlo. En mi Gentoo por ejemplo:

Mala suerte. Tal parece que el kernel no fue compilado con las opciones necesarias. Si miramos en el archivo /var/log/messages:

Por lo pronto entonces, de ahora en adelante, jugaremos un poco dentro de la seguridad que nos ofrece compilar contra el kernel que concuerda con la versión que corremos. No hay motivo para hacerlo más difícil de lo que debe ser. En el próximo artículo veremos algo acerca de las rutinas entry y exit.

Este how-to está basado en el artículo The Kernel Newbie Corner: Your First Loadable Kernel Module escrito por Rob Day en Linux.com. En él se enseñan las bases de la programación de módulos para el kernel de Linux. Este primer artículo pretende ilustrar de manera clara los conceptos básicos y espero que, a medida que Rob vaya escribiendo más artículos, pueda ir traduciéndolos para ofrecer este excelente contenido en español. Además, funciona para cualquier distro, aunque en este caso lo hice todo sobre Gentoo. Sin más, ¡vamos al grano!

¿Es necesario tener privilegios de root?

Mientras desarrollamos el módulo, no. Pero al momento de cargar el módulo necesitaremos privilegios administrativos. Por supuesto, es recomendable que el desarrollo lo hagamos con un usuario normal, y solo al final usemos un usuario root para cargar o remover los módulos.

Prerrequisitos

Antes de comenzar es necesario saber/tener algunas cosas:

• La versión del kernel con la que vamos a trabajar (usualmente la que estamos corriendo). Esto lo hacemos con el comando uname -r:
  $ uname -r
  2.6.29-gentoo-r5
• El uso de herramientas de desarrollo, como gcc, binutils, etc.
• Tener instalados las utilidades para trabajar con módulos (insmod, rmmod, etc.), el cual se encuentra en el paquete module-init-tools.
• El código del kernel de Linux, de tal manera que puedas compilar tu módulo contra este.

¿Para qué el código del kernel?

Esto es realmente importante, así que echaremos un vistazo un poco más profundo. Cuando compilamos un módulo para Linux es necesario tener el código fuente de algunas partes del kernel, puesto que muchas instrucciones de preprocesador usadas no se encuentran en los headers estándar de desarrollo. En vez de ello, se encuentran en los headers de kernel.

Podrías simplemente descargar el código del kernel directamente de la página oficial, aunque lo más sencillo es instalar el paquete que corresponda a la versión del kernel que estemos ejecutando. Por lo general, este tipo de paquetes instala el código en /usr/src o /usr/src/kernels. Por ejemplo, en Fedora el paquete que debes instalar se llama kernel-dev, mientras que en Gentoo es gentoo-sources.

Una vez tengas el código instalado, es necesario saber exactamente en donde se encuentra, de tal manera que podamos referenciarlo al momento de compilar el módulo. Podrías revisar eso manualmente o, mejor aún, buscar el enlace simbólico hacia el kernel, que por lo general se encuentra en /lib/modules:

El enlace simbólico que buscamos es build, y como puedes ver en el ejemplo, apunta a la raíz del código del kernel. Esto significa que, cada vez que quieras hacer referencia al kernel en el momento de compilar el módulo, basta con usar dicho enlace.

“Hola, kernel!”

Bien, es hora de crear nuestro primer módulo. Sin más rodeos, el código sería el siguiente:

/* El nombre del archivo es 'hola.c'. */
#include <linux/module.h>      // para todos los modulos
#include <linux/init.h>        // para las macros entry/exit
#include <linux/kernel.h>      // para usar la macro printk
#include <asm/current.h>       // informacion del proceso (solo por diversion)
#include <linux/sched.h>       // para usar la estructura "task_struct"
static int hola(void)
{
     printk(KERN_INFO "Hola, el modulo esta siendo cargado.\n");
     printk(KERN_INFO "El user space del proceso es '%s'\n", current->comm);
     printk(KERN_INFO "El PID es  %i\n", current->pid);
     return 0;       // para indicar que todo ha salido bien
}
static void adios(void)
{
     printk(KERN_INFO "Chao, el modulo esta siendo removido.\n");
}
module_init(hola);     // lo que se debe llamar al cargar un modulo
module_exit(adios);    // lo que se debe llamar al remover un modulo

MODULE_AUTHOR("Robert P. J. Day");
MODULE_AUTHOR("Cristian Castiblanco [solo lo puse en castellano]");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_DESCRIPTION("Aqui puedes poner una descripcion de tu modulo");

Algunas observaciones acerca del código de arriba:

• Técnicamente, no es necesario imprimir cosas cada vez que se carga o remueve un módulo (con printk). Pero puesto que es nuestro primer módulo, y aún no hace nada especial, es más divertido si lo dejamos así.
• Es necesario hacer que la función de inicio retorne 0, si queremos indicar que la carga fue satisfactoria.
• No, no es necesario poner una coma después de indicar el nivel de logs (KERN_INFO). Es un error común hacerlo.

Eso es todo… ¡vamos a compilarlo!

El archivo Makefile

Este es el archivo Makefile que necesitaremos:

ifeq ($(KERNELRELEASE),)  

KERNELDIR ?= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)  

.PHONY: build clean

build:
	$(MAKE) -C $(KERNELDIR) M=$(PWD) modules  

clean:
	rm -rf *.o *~ core .depend .*.cmd *.ko *.mod.c
else  

$(info Building with KERNELRELEASE = ${KERNELRELEASE})
obj-m :=    hola.o

endif

Como has de saber, los archivos Makefile indican las reglas necesarias para compilar código. En este caso, explicándolo a groso modo, lo que hace el Makefile es detectar que aún nos encontramos en el directorio de desarrollo de nuestro módulo, y por lo tanto se dirige al directorio del kernel, compila el módulo desde ahí y se devuelve. Para probarlo basta con ejecutar el comando make:

Examinar el módulo

Una vez compiles el módulo obtendrás un archivo con extensión .ko. Si quieres echarle un ojo a dicho archivo, puedes usar el comando modinfo así:

$ sudo modinfo hola.ko
filename:       hola.ko
description:    Aqui puedes poner una descripcion de tu modulo
license:        Dual BSD/GPL
author:         Cristian Castiblanco [solo lo puse en castellano ]
author:         Robert P. J. Day
depends:
vermagic:       2.6.29-gentoo-r5 SMP mod_unload CORE2

En Gentoo es necesario ejecutarlo con privilegios; en otras distros puedes ejecutarlo normalmente.

Cargar o remover el módulo

Llego la hora de cargar nuestro módulo. Para ello, como comenté anteriormente, es necesario poseer privilegios administrativos. Al grano:

¿Y donde está lo que imprimimos con printk? Bien, no es común imprimir en consola cosas mientras un módulo es cargado o removido; en este caso, la salida va a dar al archivo de logs principal de Linux (/var/log/messages); puedes ver la salida con el comando dmesg o directamente en dicho archivo:

Conclusión

Estas son apenas las bases que deberíamos tener para comenzar con la construcción de un módulo para el kernel de Linux. Es de valiosa ayuda jugar un poco con este ejemplo, de tal manera que podamos estar seguros que todo irá bien cuando hagamos algo un poco más complejo.

Descargar código fuente del ejemplo

Este es un pequeño how-to en donde explico cómo activar el soporte para el sistema de archivos ext4 en Gentoo.  El tutorial está enfocado hacia distribuciones que, como Gentoo, no tengan activado dicho soporte y en donde es necesario recompilar el kernel para hacerlo funcionar.

Espero que sirva de paso para mostrar un poco el proceso de recompilación del kernel, que a primera vista puede sonar difícil, pero que en realidad es algo muy sencillo y saludable

0. Prerequisitos

Es necesario tener el paquete e2fsprogs y las fuentes del kernel de linux. Para ello, basta con ejecutar este comando:

1. Configurando nuestro kernel

Lo que haremos a continuación será configurar el kernel para activar el soporte al sistema de archivos ext4. Para ello, abrimos una consola y entramos en el directorio donde se encuentren las fuentes, por ejemplo /usr/src/linux-2.6.30-gentoo-r5. Estando allí, iniciamos el configurador gráfico del kernel con este comando:

Una vez hayamos hecho esto, debemos navegar y dar enter en la opción File systems, y seleccionar (con la tecla espacio) The Extended 4 (ext4) filesystem. Debería quedar así:

File systems  --->
     <*> The Extended 4 (ext4) filesystem
     [ ]   Enable ext4dev compatibility
     [ ]   Ext4 extended attributes
     [ ]     Ext4 POSIX Access Control Lists
     [ ]     Ext4 Security Labels

Además, por defecto las particiones que se crean con ext4 tienen activada la opción huge_file, lo cual permite que se manejen ficheros de un gran tamaño. Por ello, es necesario activar la opción Support for Large single files del kernel. Dicha opción se encuentra en Enable the block layer y debería lucir así:

Enable the block layer --->
     --- Enable the block layer
     [*]   Support for Large single files

Una vez hayamos configurado el kernel, salimos de la configuración presionando el botón exit, compilamos e instalamos:

2. Crear y montar particiones con el sistema de archivos ext4

Para ello basta con usar el comando mkfs.ext4, por ejemplo:

Para montar la partición:

3. Convirtiendo ext3 a ext4

Ten en cuenta que puedes montar una partición ext3 con la opción -t ext4 y todo funcionará bien, aunque no tendrás disponibles las características de ext4. Si deseas, puedes convertir una partición que se encuentra en ext3 a ext4. Para ello puedes ejecutar el siguiente comando:

Es recomendable hacer un chequeo de la partición para verificar que todo haya salido bien:

Más información:

http://fr.gentoo-wiki.com/wiki/Ext4

Hola amigos… he grabado un pequeño vídeo en donde enseño cómo ejecutar varios sistemas operativos REALES, es decir, que no son virtuales, al mismo tiempo usando VirtualBox. Por ejemplo, si tienes instalado Windows XP, Ubuntu y Fedora, y en cada uno tienes aplicaciones que usas a diario, podrías ejecutar Windows XP desde Ubuntu sin necesidad de tener que reiniciar el equipo.

Esto tiene una gran ventaja frente al típico entorno en el cual tienes máquinas virtuales instaladas ya que, cuando realmente quieras usar el otro sistema operativo, lo ejecutas directamente en tu máquina sin las limitaciones de RAM o aceleración gráfica. Es más o menos lo que explicaba en esta entrada, en donde lo hacia con Windows XP. Pero puesto que algunos han tenido problemas con eso, y otros más me han pedido algo de información más detallada, mejor dejar todo registrado en este vídeo.

Como siempre lo he subido en Blip.tv, Youtube y Vimeo. El vídeo es completamente libre, puedes darle el uso que desees; si deseas el vídeo original para cualquier propósito me contactan por correo.

Objetivo

Instalar el reproductor de Flash como plugin para Firefox, compatible con Youtube usando Portage.

1. Preparar los ebuilds para Portage

Lo primero es hacer login como root en una consola; luego creamos un árbol de directorios para los nuevos ebuilds:

Es buena idea leer un poco la entrada creada para el swfdec, en el centro de bugs de Gentoo. Allí podrás encontrar todos los ebuild para usar emerge e instalar SWFDEC:

1. swfdec-0.4.3-r1.ebuild, copiarlo a /usr/local/portage/flash/media-libs/swfdec
2. ffmpeg-fix.patch copiarlo a /usr/local/portage/flash/media-libs/swfdec/files
3. swfdec-mozilla-0.4.3.ebuild, copiarlo a /usr/local/portage/flash/net-www/swfdec-mozilla

Luego copiamos los archivos fuente a /usr/portage/distfiles:

2. Configurar Portage

Ahora debemos configurar a Portage para que instale correctamente los paquetes; abrimos el archivo make.conf:

Añadimos este línea:

PORTDIR_OVERLAY="$PORTDIR_OVERLAY /usr/local/portage/flash"

Luego creamos los archivos digests para los paquetes:

3. Instalar los paquetes

Para llevar a cabo la instalación ejecutamos los siguientes comandos:

Fuente