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

En este pequeño manual explicare la manera de instalar Gentoo de una forma sencilla, simple, ilustrada y rápida, este proceso incluye instalación de Gentoo para x86 y AMD (32bits y 64bits), a su vez, puede también tomarse este manual como una opción alternativa a los manuales Oficiales de Gentoo…

Descargar [licencia cc]

Página del autor

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

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

Continuando con la experiencia en PC-BSD, veremos cómo configurar la red. Los pasos son similares a como se haría en Linux, aun así, puesto que algún par de cosas cambian, he preferido dejarlo documentado.

Lo primero que deberíamos hacer es identificar el nombre que el sistema le ha dado a nuestras tarjetas, en mi caso la tarjeta es le0 (que es el equivalente al típico eth0 en Linux). Para hacerlo basta con ejecutar desde una consola el comando ifconfig.

Configuración manual de la red

Para configurar manualmente nuestra red podemos ejecutar los siguientes comandos:

Explicación

• En el primero comando usamos ifconfig para configurar la interfaz de red le0, con la dirección IP 192.168.16.8 y la máscara de red 255.255.255.0. La opción up activa la interfaz de red.
• Posteriormente usamos el comando route para añadir el gateway por defecto de la red.
• El comando netstat -r nos permite verificar que el gateway fue añadido correctamente. Interesante tener en cuenta que, a diferencia de Linux, para mirar las tablas de enrutamiento no se usa route -n sino netstat -r

Configurar la interfaz de red con DHCP

Esta es la opción más sencilla y la que recomiendo. Si tienes un servidor DHCP en la red, lo mejor será configurar nuestra interfaz de red para que solicite una IP automáticamente. Para ello basta con abrir el archivo /etc/rc.conf y modificar nuestra interfaz de red de tal manera que quede así:

Además, si estás usando otro cliente DHCP diferente del que trae por defecto el sistema, o quieres ejecutarlo con alguna opción en especial, debes modificar estas variables:

Hace rato quería probar algún sistema BSD, y al final me he decidido por PC-BSD por su amabilidad con el usuario novel. A veces, al hablar de BSD, lo primero que se piensa es en un servidor o algo así, pero gracias a proyectos como PC-BSD podemos tener un BSD como sistema de escritorio, y con ello, disfrutar la estabilidad y seguridad que nos ofrece (sí, mucho más estable y seguro que Linux).

¿Qué es PC-BSD?

PC-BSD es un sistema operativo basado en FreeBSD. Puesto que bajo PC-BSD se encuentra un sistema FreeBSD, cuentas con todas las ventajas de velocidad y seguridad que éste proporciona. Es importante tener en cuenta que PC-BSD NO es una distribución de Linux. Ambos están basados en UNIX, pero PC-BSD está basado en FreeBSD y no en Linux.

Existen algunas diferencias entre PC-BSD y FreeBSD. PC-BSD está pensado ser usado como sistema de escritorio, mientras que FreeBSD fue concebido sobre todo para usarse como servidor. Además PC-BSD ofrece un instalador gráfico y el escritorio KDE, tiene un gran número de aplicaciones de escritorio pre-instaladas y, aunque soporta el sistema de ports de FreeBSD, proporciona un método de instalación sencillo de paquetes precompilados.

Además, el kernel de PC-BSD ha sido recompilado con algunas modificaciones de tal manera que tenga un mejor comportamiento como sistema de escritorio. E incluso incluye los drivers para las tarjetas aceleradoras de video NVIDIA.

Instalación

Lo primero es ir a la página de descargas y bajar la ISO que deseemos. Las ISOs más importantes son:

PC-BSD 32Bit (i386)

• PC-BSD CD #1 32bit (i386) – System install CD1
• PC-BSD CD #2 32bit (i386) – System Install CD2
  
• PC-BSD CD #3 32bit (i386) – Multi-language support + Optional Components
• PC-BSD DVD 32bit (i386) – Complete install + Optional Components

PC-BSD 64Bit (amd64)

• PC-BSD CD #1 64bit (amd64) – System install CD1
• PC-BSD CD #2 64bit (amd64) – System Install CD2
  
• PC-BSD CD #3 64bit (amd64) – Multi-language support + Optional Components
• PC-BSD DVD 64bit (amd64) – Complete install + Optional Components

Una vez hayamos descargado la imagen y la hayamos quemado en un CD, es hora de insertarlo en el PC y bootear desde él. Esto cargará el instalador de  PC-BSD, siendo la primera opción la selección de nuestro idioma, la distribución del teclado y la zona horaria:

Aceptamos los términos de la licencia:

En el siguiente paso decidimos si vamos a realizar una instalación nueva, el tipo de sistema a instalar (Desktop o Server), así como la fuente de los paquetes a instalar. Yo escogí Desktop por supuesto:

Luego ponemos el password que le daremos al usuario root, y creamos un usuario con privilegios que será nuestro usuario. Es recomendable que, si eres usuario de Linux, selecciones bash como la shell por defecto del usuario:

Seleccionamos el disco sobre el cual haremos la instalación. En este caso, para propósitos de documentación lo instalé en una máquina virtual, por lo que uso todo el disco. En tu caso podrías usar el asistente de partición:

Es hora de escoger el software adicional que queremos instalar, teniendo en cuenta que el sistema de escritorio es KDE:

En este punto ya hemos configurado todo lo necesario para dar inicio a la instalación; clic en Next:

El progreso de la instalación…

¡Y eso es todo! Damos clic en Reboot, removemos el CD de instalación y ya tenemos un BSD instalado.

Una vez hemos iniciado nuestro PC-BSD configuramos la resolución de la pantalla…

Iniciamos sesión desde el KDM:

Enlaces interesantes…

• Página oficial del proyecto PC-BSD: http://pcbsd.org/
• Foros de ayuda: http://forums.pcbsd.org/
• Descarga PC-BSD

Slim es un gestor de inicio de sesión para X11 bastante liviano y sencillo; es el reemplazo perfecto para el GDM o el KDM si usas máquinas no tan nuevas, o si simplemente quieres agilizar el proceso de inicio de tu PC. Yo lo uso sobre todo en máquinas con XFCE, lo cual hace todo bastante ligero y rápido.

Instalación

Para instalarlo debes ejecutar el siguiente comando:

En Ubuntu/Debian:

En Gentoo:

En Arch:

En Fedora:

Una vez instalado, procedemos a la configuración.

Configuración en Gentoo

Lo pongo solo en Gentoo porque fue la primer distribución en la que hice esto, y además otras distros lo configuran automáticamente una vez instalado. Lo primer es hacer que el XDM inicie en el runlevel por defecto:

Luego, debemos configurarlo para que ejecute slim. Para ello debes modificar la variable DISPLAYMANAGER en el archivo /etc/conf.d/xdm:

...
DISPLAYMANAGER="slim"
...

Ahora, debemos configurar las sesiones con las que se puede iniciar sesión con Slim. Esto se hace editando el archivo /etc/slim.conf y configurando la variable session de acuerdo a nuestras necesidades (Gnome, XFCE, KDE, etc.). En mi caso está así:

# Available sessions (first one is the default).
# The current chosen session name is replaced in the login_cmd
# above, so your login command can handle different sessions.
# see the xinitrc.sample file shipped with slim sources
sessions xfce4,Gnome

Cuando estés enfrente de la pantalla de inicio de sesión, basta con presionar F1 para rotar entre las sesiones que tengas configuradas. Si no lo haces, Slim iniciará la sesión por defecto (en el caso de la configuración de arriba, iniciará XFCE).

Algo recomendable es cambiar la manera en que Slim inicia sesión, y crear un script personalizado para cada usuario (si hay más de uno). Los pasos en mi caso fueron: crear un archivo llamado .xinitrc en mi directorio personal con el siguiente contenido:

#!/bin/bash
DEFAULTSESSION=startxfce4
case "$1" in
	"Gnome")
		exec gnome-session
		;;
	"xfce4")
		exec startxfce4
		;;
	*)
		exec $DEFAULTSESSION
		;;
esac

Luego modifiqué la variable login_cmd poniéndola de esta manera:

login_cmd           exec /bin/sh - ~/.xinitrc %session

Instalación de Themes

Si quieres cambiar la apariencia, puedes descargar alguno de los Themes disponibles para Slim y descomprimirlo en la carpeta /usr/share/slim/themes:

Y luego modificas la variable current_theme del archivo /etc/slim.conf, por ejemplo:

current_theme       xfce-g-box

Puedes también poner varios temas separados por coma lo cual hará que los cargue de manera aleatoria. Podrías también leer la documentación acerca de cómo crear un nuevo theme, es bastante fácil.

Troubleshooting

Si al presionar F1 en el momento en el que te estás logueando no aparecen los nombres de las sesiones, y en vez de ello aparece una línea extraña como de bash, elimina o comenta estas líneas en el archivo /etc/slim.conf:

# Needed so your login will show up in wtmp and utmp, etc
#sessionstart_cmd /usr/bin/sessreg -a -l :0.0 %user
#sessionstop_cmd /usr/bin/sessreg -d -l :0.0 %user

De nuevo algo de inconvenientes con el audio; espero mejorar cada vez más.

Video en Vimeo

Descargar video

Video en Blip.tv

Video en Youtube

Información complementaria: Tamaños de las variables de tipo primitivo

• char: 16 bits; ‘\u0000′ hasta ‘\uFFFF’ (Conjunto de caractéres Unicode de ISO) o 0 hasta 65535 (ASCII)
• byte: 8 bits; -128 hasta +127 (-27 hasta 27-1)
• short: 16 bits, -32768 hasta 32767 (-215 hasta 215-1)
• int: 32 bits; -2147483648 hasta +2147483647 (-231 hasta 231-1)
• long: 64 bits; -9223372036854775808 hasta +9223372036854775807 (-263 hasta 263-1)
• float: 32 bits; rango negativo -3.4028234663852886E+38 hasta -1.40129846432481707e-45, rango positivo 1.40129846432481707e-45 hasta 3.4028234663852886E+38
• Double: 64 bits; rango negativo -1.7976931348623157E+308 hasta – 4.94065645841246544e-324, rango positivo 4.94065645841246544e-324 hasta 1.7976931348623157E+308