Dentro del núcleo Linux 2.4 - Procesando la linea de comandos del núcleo

Déjanos recalcar qué es lo que le pasa a la linea de comandos cuando se le pasa al núcleo durante el arranque:

1. LILO (o BCP) acepta la linea de comandos usando los servicios de teclado de la BIOS y los almacena en una localización bien conocida en la memoria física, también como una firma diciendo que allí existe una linea de comando válida.
2. arch/i386/kernel/head.S copia los primeros 2k de ella fuera de la página cero. Nótese que la actual versión de LILO (21) corta la linea de comandos a los 79 bytes. Esto es un fallo no trivial en LILO (cuando el soporte para EBDA grandes está activado) y Werner prometió arreglarlo próximamente. Si realmente necesitas pasarle lineas de comando más grandes de los 79 bytes, entonces puedes usar BCP o codificar tu linea de comandos en la función arch/i386/kernel/setup.c:parse_mem_cmdline().
3. arch/i386/kernel/setup.c:parse_mem_cmdline() (llamada por setup_arch(), y esta llamada por start_kernel()) copia 256 bytes de la página cero a saved_command_line la cual es mostrada por /proc/cmdline. Esta misma rutina procesa la opción "mem=" si está presente y realiza los ajustes apropiados en los parámetros de la VM.
4. Volvemos a la línea de comandos en parse_options() (llamada por start_kernel()) el cual procesa algunos parámetros "dentro del núcleo" (actualmente "init=" y entorno/argumentos para init) y pasa cada palabra a checksetup().
5. checksetup() va a través del código en la sección ELF .setup.init y llama a cada función, pasándole la palabra si corresponde. Nótese que usando el valor de retorno de 0 desde la función registrada a través de setup(), es posible pasarle el mismo "variable=value" a más de una función con el "value" inválido a una y válido a otra. Jeff Garzik comentó: "los hackers que hacen esto son buenos :)" ¿Por qué? Porque esto es claramente específico del orden de enlazado, esto es, el enlazado del núcleo en un orden tendrá a la llamada de la funciónA antes de la funciónB y otro los tendrá en orden inverso, con el resultado dependiendo del orden.

Por lo tanto, ¿cómo debemos de escribir el código que procesa la linea de comandos del arranque? Nosotros usamos la macro setup() definida en include/linux/init.h:

---

/*
* Usado por la configuración de parámetros de la línea de comandos
* del núcleo
*/
struct kernel_param {
const char *str;
int (*setup_func)(char *);
};

extern struct kernel_param setup_start, setup_end;

#ifndef MODULE
#define setup(str, fn) \
static char setup_str_fn[] initdata = str; \
static struct kernel_param setup_fn initsetup = \
{ setup_str_fn, fn }

#else
#define setup(str,func) /* nada */
endif

---

Por lo tanto, típicamente la usarás en tu código de esta forma (tomado del código del controlador real, BusLogic HBA drivers/scsi/BusLogic.c):

---

static int init
BusLogic_Setup(char *str)
{
int ints[3];

(void)get_options(str, ARRAY_SIZE(ints), ints);

if (ints[0] != 0) {
BusLogic_Error("BusLogic: Obsolete Command Line Entry "
"Format Ignored\n", NULL);
return 0;
}
if (str

NULL || *str

'\0') return 0;
return BusLogic_ParseDriverOptions(str);
}

setup("BusLogic=", BusLogic_Setup);

---

Destacar que setup() no hace nada por los módulos, por lo tanto el código que quiere procesar la linea de comandos del arranque, que puede ser un módulo o estar estáticamente enlazado, debe de ser llamado pasándole la función manualmente en la rutina de inicialización del módulo. Esto también significa que es posible escribir código que procese los parámetros cuando es compilado como un módulo pero no cuando es estático o viceversa.