POSIX: INT_MAX, INT_MIN and SIGFPE

En sistemas operativos modernos, los límites de direccionamiento de memoria y cantidad de procesos/threads está estipulada de dos formas: la primera acorde al hardware específico con que cuenta el equipo, y la segunda, mediante configuración específica del sistema operativo.

A modo de ejemplo, y para dejar las cosas más en claro, vamos a hablar un poco sobre los límites de los procesos: Cada proceso en el sistema operativo ocupa un slot en una estructura de datos denominada kernel process table. Esta tabla contiene toda la información necesaria que el kernel mantiene a fin de poder manejar los procesos, schedulear las distintas tareas (acorde a sus prioridades) y estados de los mismos. Cuando el OS bootea, el kernel inicializa una estructura de datos denominada process_cache, donde comenzará a direccionar la estructura de procesos que luego serán empleada por el kernel y el userspace. Esta tabla es una lista doblemente enlazada con dos punteros, uno a su elemento anterior y otro a su elemento posterior, la cual tiene una capacidad máxima que se define acorde a la cantidad de memoria física instalada en el equipo. El sistema operativo, para esto asigna la cantidad de memoria instalada a una variable MAX_MAXUSERS (que no tiene nada que ver con el número máximo de usuarios que el sistema soporta), que luego será utilizada por dos variables más del propio kernel max_nprocs y maxuprc. max_nprocs define el número máximo de procesos del sistema operativo, y maxuprc determina el número máximo de procesos que usuarios no privilegiados (que no sean root), puedan crear y ocupar slots en la kernel process table. Y basándose en el valor de MAX_MAXUSERS, poder definir el tamaño en memoria de cada segmento del proceso (región .text, .stack, .heap, .bss, etc.).

Installing Fedora 16 in non GPT partition table.

En mi laptop del trabajo, por una cuestión de practicidad utilizo Fedora 16, es una distro que me resulta bastante cómoda, debido a que diariamente suelo trabajar con Linux, especificamente con RHEL y CentOS.

Como muchos saben las nuevas features de RHEL, previamente se incorporan a Fedora para que la comunidad las pruebe primero, y fue así, como por ejemplo, comencé a familiarizarme con Systemd (el remplazo de LSB Scripts). 

Una de las características que incorpora Fedora 16, y no Fedora 15, es que por default utiliza GPT (GUID Partition Table), en lugar de MBR (Master Boot Record) como se venía haciendo en las arquitecturas x86 y 86_64. GPT forma parte del estándar EFI (Extensible Fimreware Interface) y es propuesto por Intel para reemplazar PC BIOS. Entre las ventajas prácticas que incorpora GPT es que limita el tamaño máximo de la partición 9.4 zettabytes, mientras que este límite para MBR es de 2.4 terabytes y la cantidad de particiones definidas en en el disco. 

FreeBSD: Enabling ALTQ support for PF queues

Hace unos días, en DC Solutions migramos en un cliente un Firewall que utilizaba la tecnología FreeBSD/IPFilter, a FreeBSD/Packet Filter a fin de poder soportar queues para permitiri una priorización del tráfico VoIP y además aliviar el bug descrito en este post IPF NAT entry causes kernel crash.
No voy a describir las ventajas de utilizar una tecnología como PF sobre IPF (aunque pueden ver este post), sino que solo voy a comentarles como darle soporte a las queues dentro del kernel de FreeBSD, el cual no se encuentra soportado por default dentro del kernel instalado con el sistema operativo, sino que debemos activarlo modificando el archivo de configuración del kernel.

FreeBSD: Supporting DTrace

Hace unos días en marco del BSDDay 2011 asistí a una charla de Fer Gleiser donde explicaba el uso de una herramienta increible como es DTracre. Así que partiendo de que tengo un FreeBSD instalado en mi notebook personal, decidí comenzar a aprender esta nueva herramienta.

Como primera medida, es necesario tener instaladas las fuentes del kernel, por lo que para hacer esto, es necesario ejecutar sysinstall

Linux: The kernel SysRq and the SAK key.

Muchos usuarios de Linux, no conocen la existencia de dos combinaciones de teclas que suelen resultar muy útiles a la hora de que un equipo no responda, o al momento de loguearse en uno.

SysRq key:
Cuando hablamos de kernel SysRq key, nos referimos a una combinación de teclas especial, la cual va a realizar que un equipo paniqueado, ocrasheado, sea capaz de responder, y poder rebootear de una manera un poco más suave que dandole el botonazo.

Para poder hacer uso y utilización de esta combinación de teclas, debemos previamente tener soporte a esta en la configuración del kernel, para ello buscamos, en el archivo config de este el siguiente string, que representa un valor booleano:

#: cat /boot/config-2.6.40.4-5.fc15.x86_64 | grep -i sysrq
CONFIG_MAGIC_SYSRQ=y

En este caso se encuentra soportado, en caso contrario, habría que recompilar el kernel, dandole soporte en dicha directiva de configuración. 

RHEL/CentOS: Examining and building the initial ramdisk

Como muchos de ustedes seguramente sabrán, al bootear un equipo, es necesario tener cargados ciertos módulos como el de la controladora de disco (ATA/SATA/SCSI), filesystems, manejo de memoria, entre otros, para de esta forma poder realizar la secuencia normal de booteo e inicio del sistema.

Pero, aquí entramos en el clásico problema "The Chicken/Egg problem". ¿Como el OS monta la rootfs, si aún no tiene cargado los módulos?. Es que para ello existe, mis queridos amigos el initial RAM disk, o mejor conocido como initrd. Un filesystem temporal, utilizado por el kernel, que al momento del booteo es cargado en /dev/ram0. El kernel utilizará en un principio dicho RAM disk, como rootfs, hasta que el kernel monte el rootfs real, y lo posicione como tal mediante la syscall pivot_root.
Esto se realiza, escribiendo el número del real rootfs en el archivo /proc/sys/kernel/real-root-dev.  Un ejemplo de ello podría ser:

# echo 0x301 >/proc/sys/kernel/real-root-dev

Ustedes sabrán que dentro del kernel, los módulos pueden ser compilados, built-in, osea construidos dentro de este o en forma de modulo, siendo cargados a medida que se necesitan.
Construir un kernel, con todos los drivers necesarios buil-in, daría lugar a un kernel pesado, y mas lento. Es por ello que estos drivers esenciales, que deben cargarse en algún momento del booteo del equipo, deben ser incluido en el initial RAM disk.