1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
|
<!-- $FreeBSD$ -->
<!-- The FreeBSD Documentation Spanish Project -->
<sect>
<heading>Sólo para hackers serios de FreeBSD<label id="hackers">
</heading>
<sect1>
<heading>
¿Qué son SNAPs y RELEASEs?
</heading>
<p>Hay actualmente tres ramas activas/semi-activas en el desarrollo de
FreeBSD y en su
<url url="http://www.FreeBSD.org/cgi/cvsweb.cgi" name="CVS Repository">:
<itemize>
<item><bf/RELENG_2_2/ AKA <bf/2.2-stable/ AKA <bf/"2.2 branch"/
<item><bf/RELENG_3/ AKA <bf/3.x-stable/ AKA <bf/"3.0 branch"/
<item><bf/HEAD/ AKA <bf/-current/ AKA <bf/4.0-current/
</itemize>
<p><bf/HEAD/ no es una rama actual, como las otras dos, es
simplemente una constante simbólica para <em/la versión
de desarrollo actual/ a la cual nos referimos simplemente como
<bf/-current/.
<p>Actualmente, <bf/-current/ es el desarrollo de la versión 4.0 y
la rama <bf/3.0-stable/ es <bf/RELENG_3/, separada de -current en Enero
de 1999.
<sect1>
<heading>
¿Cómo puedo hacerme mi propia release personalizada?<label id="custrel">
</heading>
<p>Para hacer una release necesitas hacer tres cosas: primero,
necesitas usar un kernel con el driver <htmlurl
url="http://www.FreeBSD.org/cgi/man.cgi?vn" name="vn"> configurado.
Añade esto a tu fichero de configuración del kernel y
crea un nuevo kernel:
<verb>
pseudo-device vn #Vnode driver (turns a file into a device)
</verb>
<p>Segundo, debes tener las herramientas del CVS a mano. Para hacer
esto, puedes usar
<url url="../../handbook/synching.html#CVSUP" name="CVSUP">
pero en tu supfile pon el nombre de la release a cvs y borra cualquier
tag campo de fecha:
<verb>
*default prefix=/home/ncvs
*default base=/a
*default host=cvsup.FreeBSD.org
*default release=cvs
*default delete compress use-rel-suffix
## Main Source Tree
src-all
src-eBones
src-secure
# Other stuff
ports-all
www
doc-all
</verb>
<p>A continuación ejecuta <tt/cvsup -g supfile/ para tener todos
los bits correctos en tu ordenador.
<p>Finalmente, necesitas una buena cantidad de espacio vacío para
crear en el la release. Digamos que está en
<tt>/algun/disco/grande</tt> y en el ejemplo anterior has dejado los
ficheros del CVS en <tt>/home/ncvs</tt>:
<verb>
setenv CVSROOT /home/ncvs # or export CVSROOT=/home/ncvs
cd /usr/src/release
make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/algun/disco/grande/release
</verb>
<p>Una release completa será creada en
<tt>/algun/disco/grande/</tt> y tendrás una instalación
completa de tipo FTP en <tt>/algun/disco/grande/R/ftp</tt> cuando acabes.
Si quieres crear tu SNAP usando otra rama de desarrollo diferente de
-current, puedes añadir <tt/RELEASETAG=SOMETAG/ a la línea
de comando anterior de creación de la release. Por ejemplo,
<tt/RELEASETAG=RELENG_2_2/ crearía un snapshot 2.2 GAMMA.
<sect1>
<heading>¿Cómo creo discos de instalación personalizados?</heading>
<p>El proceso completo de creacación de discos de
instalación y archivos fuentes y binarios esta automatizado por
varios targets en <tt>/usr/src/release/Makefile</tt>. La
información alli contenida debería ser suficiente para que
puedas empezar. Falta decir que este proceso necesita la ejecución
del comando "make world" y quizás te use mucho tiempo y espacio
en disco.
<sect1>
<heading>``make world'' destruye mis binarios instalados.</heading>
<p>Sí, esta es la idea general; como su nombre sugiere,
"make world" rehace todos los binarios del sistema, de manera que puedas
estar seguro de tener un entorno limpio y consistente al final (que es
por lo que tarda tanto).
<p>Si la variable de entorno <tt/DESTDIR/ está definida mientras se
ejecuta <tt/make world/ o <tt/make install/, los binarios creados
nuevamente seran depositados en un árbol de directorios
idéntico al instalado, y a partir de
<tt>${DESTDIR}</tt>. Algunas combinaciones aleatorias
de modificaciones de librerías compartidas y programas pueden
causar que falle el <tt/make world/.
<sect1>
<heading>
Cuando mi sistema arranca, dice (bus speed defaulted).
</heading>
<p>Las controladoras SCSI Adaptec 1542 permiten al usuario configurar
su velocidad de acceso al bus en software. Versiones anteriores del
driver de la 1542 intentaban determinar la velocidad más alta
factible y configurar la Adaptec a esta. Nos hemos encontrado con que esto
hace fallar el sistema de algunos usuarios, por lo que tienes que
definir la opción de configuración del kernel
<tt/TUNE_1542/ para que esto ocurra. En algunos sistemas puede
que puede hacer que los discos vayan más rápidos, pero en
otros puede que los datos queden corrompidos.
<sect1>
<heading>
¿Puedo seguir la rama current con acceso limitado a Internet?<label id="ctm">
</heading>
<p>Sí, puedes hacerlo <tt/sin/ bajarte todo el código
fuente usando la
utilidad <url url="../../handbook/synching.html#CTM" name="CTM.">
<sect1>
<heading>¿Cómo partir la distribución en ficheros de 240k?</heading>
<p>Los sistemas BSD más modernos tienen una opción
<tt/-b/ para partir que les permite partir los ficheros en
tamaños arbitrarios.
<p>Aqui hay un ejemplo de <tt>/usr/src/Makefile</tt>.
<verb>
bin-tarball:
(cd ${DISTDIR}; \
tar cf - . \
gzip --no-name -9 -c | \
split -b 240640 - \
${RELEASEDIR}/tarballs/bindist/bin_tgz.)
</verb>
<sect1>
<heading>¿He escrito una extensión del kernel, a quien la
envío?</heading>
<p>Por favor, mira en <url url="../../handbook/contrib.html"
name="como enviar código.">
<p>Y gracias por pensar en nosotros!
<sect1>
<heading>¿Cómo se detectan e inicializan las tarjetas ISA y PnP?</heading>
<p>Brevemente, hay unos cuantos puertos de entrada/salida a los que
todas las tarjetas PnP responden cuando el ordenador pregunta si hay
alguien ahí. Así, cuando comienza la rutina de prueba
de PnP, pregunta si hay alguna tarjeta PnP presente y todas las
tarjetas responden con su número de modelo a una lectura I/O
del mismo puerto. Así el código de prueba puede conocer
el ID de cada tarjeta (asignado por Microsoft/Intel).
<p>Los ID's son dos campos de 32 bits (2ˆ64) + 8 bits de
checksum. Los primeros 32 bits son el identificador del fabricante.
No se ha dicho publicamente, pero parece estar asumido que diferentes
tipos de tarjeta del mismo fabricante pueden tener diferentes id's de
fabricante. La idea de necesitar 32 bits sólo para los
fabricantes parece un poco excesiva.
<p>La parte baja de 32 bits son un número de serie,
dirección ethernet, algo que haga a la tarjeta única. El
fabricante no debe producir nunca una segunda tarjeta que tenga los
mismos 32 bits de la parte baja, aunque los 32 bits de la parte alta sean
diferentes. Así puedes tener múltiples tarjetas del mismo
tipo en la misma máquina y los 64 bits serán únicos
para cada tarjeta.
<p>Los grupos de 32 bits nunca pueden ser todos cero. Esto permite
mostrar todos los bits no-cero durante la búsqueda binaria
inicial.
<p>Una vez el sistema ha identificado todos los ID's de las tarjetas
presentes, reactivaráa cada tarjeta, una tras otra (a
través de los mismos puertos I/O), y encontrará los
recursos que cada tarjeta necesita, que opciones de interrupción
están disponibles, etc. Se realiza un escaneo sobre todas y cada
una de las tarjetas presentes para conocer esta información.
<p>Esta información se combina con la información de los
ficheros ECU del disco y con las BIOS MLB. El soporte PnP de ECU y las
BIOS para hardware en el MLB usualmente es sintético, y los
periféricos no hacen PnP genuino. De todas maneras, examinando
la información de la BIOS más la información
ECU, la rutina de prueba puede causar que los dispositivos que no son
PnP puedan evitar a esos dispositivos que el código de prueba
no puede volver a posicionar.
<p>Así, los dispositivos PnP son visitados una vez más
y se les asigna su I/O, DMA, IRQ, direcciones del mapa de memoria. Los
dispositivos aparecerán en esas direcciones y permanecerán
en ellas hasta que se vuelva a reinicializar la máquina.
<p>Todo el proceso se ha simplificado mucho, pero espero que hayas podido
hacerte una idea del proceso.
<sect1>
<heading>¿Soporta FreeBSD arquitecturas diferentes a x86?</heading>
<p>Diferentes grupos de personas han expresado su interés en
trabajar en un port multi-arquitectura de FreeBSD y FreeBSD/AXP
(ALPHA) es un ejemplo de ese esfuerzo realizado, ahora disponible en
forma de 3.0 SNAPshot release en <url
url="ftp://ftp.FreeBSD.org/pub/FreeBSD/alpha/"
name="ftp://ftp.FreeBSD.org/pub/FreeBSD/alpha">. El port de ALPHA
funciona actualmente en diferentes tipos de máquinas ALPHA,
entre ellas, AlphaStation, AXPpci, PC164, Miata y Multia. Este port
todavía no se considera una release completa y no lo será
hasta que exista una colección completa de herramientas de
instalación y una distribución completa en cdrom para
instalació, incluyendo un número razonable de ports y
packages funcionales. FreeBSD/AXP debe considerarse software de
calidad BETA en estos momentos. Para más información del
proyecto, subscríbete a la
<tt><FreeBSD-alpha@FreeBSD.org></tt><ref id="mailing"
name="lista de correo">.
También se ha expresado interés en un port de FreeBSD para
arquitectura SPARC. Subscríbete a
<tt><FreeBSD-sparc@FreeBSD.org></tt> <ref id="mailing"
name="la lista"> si estás interesado en participar en el proyecto.
Para discusiones generales en nuevas arquitecturas, participa en
<ref id="mailing" name="la lista">
<tt><FreeBSD-platforms@FreeBSD.org></tt>.
<sect1>
<heading>Necesito un numero de dispositivo para un driver propio</heading>
<p>Esto depende de si quieres hacer que el driver esté
públicamente disponible. Si la respuesta es afirmativa, por favor,
envianos una copia del código fuente del driver y las
modificaciones apropiadas del fichero <tt>files.i386</tt>, un ejemplo de
configuración y el código apropiado de <htmlurl
url="http://www.FreeBSD.org/cgi/man.cgi?MAKEDEV" name="MAKEDEV"> para
crear cualquier fichero especial que use tu dispositivo. Puedes enviar
todo lo necesario a <tt><FreeBSD-hackers@FreeBSD.org></tt>.
<sect1>
<heading>Alternativas a la política de directorios</heading>
<p>En respuesta a esta pregunta de políticas alternativas
para los directorios, el esquema que está actualmente en uso
no ha cambiado desde que lo escribí en 1983. Escribí esa
política para el sistema de ficheros rápido original, y
nunca se ha revisado. Trabaja bién manteniendo los grupos de
cilindros. Como muchos de vosotros habreis notado, el rendimiento es
muy pobre con "find". Muchos sistemas de ficheros son creados desde
archivos que fueron creados por una primera búsqueda en
profundidad (también conocido como ftw). Estos directorios
terminan esparcidos a través de los grupos de cilindros. Si
conociesemos el número total de directorios a crear, la
solución sería crear (total / fs_ncg) por grupo de
cilindros antes de moverlos. Obviamente, tendriamos que crear
algún tipo de heurística para adivinar este número.
Usando un número pequeño fijo (como puede ser
10) haría de orden de magnitud. Para diferencial restores de
operaciones normales (cuando el algoritmo actual es probablemente
más sensible), podrís usar el clustering hasta 10 si
fueran todos hechos dentro de una ventana de diez segundos. De cualquier
manera, mi conclusión es que este es un área para la
experimentación.</p>
<p>Kirk McKusick, Septiembre 1998</p>
<sect1>
<heading>Obtener todo lo posible de un "kernel panic"</heading>
<p>
<em>[Esta sección fue extraida de un mensaje escrito por <url
url="mailto:wpaul@FreeBSD.org" name="Bill Paul"> en la
<ref id="mailing" name="lista"> FreeBSD-current por <url
url="mailto:des@FreeBSD.org" name="Dag-Erling Coïdan
Smørgrav">, quién a fijado algunos errores y
añadido algunos comentarios entre corchetes]</em>
<p>
<verb>
From: Bill Paul <wpaul@skynet.ctr.columbia.edu>
Subject: Re: the fs fun never stops
To: ben@rosengart.com
Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT)
Cc: current@FreeBSD.org
</verb>
<p>
<em>[<ben@rosengart.com> envió el siguiente panic]</em>
<verb>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x40
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xf014a7e5
^^^^^^^^^^
> stack pointer = 0x10:0xf4ed6f24
> frame pointer = 0x10:0xf4ed6f28
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 80 (mount)
> interrupt mask =
> trap number = 12
> panic: page fault
</verb>
<p>[Cuando] ves un mensaje como este, no es suficiente con solo
reproducirlo y enviarlo. El valor del puntero de instrucciones que
he marcado arriba es importante; desafortunadamente, depende de la
configuración. En otras palabras, el valor varía
dependiendo de la imáden de kernel exacta que se use. Si
estás usando el kernel GENERIC de uno de los snapshots, entonces
es posible que alguien pueda seguir la función
problemática, pero si estás usando un kernel
personalizado, entonces solo <em>tú</em> puedes decirnos donde
ha ocurrido el fallo.
<p>Tendrías que hacer lo siguiente:
<itemize>
<item>Anotar el valor del puntero de la instrucción. Ten en
cuenta la parte <tt/0x8:/ al inicio no es significante en este caso:
es la parte <tt/0xf0xxxxxx/ la que queremos.
<item>Cuando el sistema rearranca, haz lo siguiente:
<verb>
% nm /kernel.that.caused.the.panic | grep f0xxxxxx
</verb>
donde <tt/f0xxxxxx/ es el valor del puntero de la instrucción.
El problema es que no obtendrás una búsqueda exacta ya
que los símbolos en la tabla de símbolos del kernel
son para los puntos de entrada de las funciones y la dirección
del puntero de la instrucción estará en algún
lugar dentro de una función, no al principio. Si no obtienes
un resultado exacto, omite el último dígito del valor
del puntero de la instrucción e intentalo otra vez, por
ejemplo:
<verb>
% nm /kernel.that.caused.the.panic | grep f0xxxxx
</verb>
Si esto no da ningún resultado, elimina otro dígito.
Repite la operación hasta que obtengas algún tipo de
salida. El resultado será una lista de posibles funciones
que causan el panic. Este no es un sistema muy exacto de
búsqueda de errores, pero es mejor que nada.
</itemize>
<p>Veo gente que constantemente envía mensajes de panics como
este, pero raramente veo que alguien se tome el tiempo de buscar
la coincidencia entre el puntero de instrucción y una
función en la tabla de símbolos del kernel.
<p>La mejor manera de hacer el seguimiento de la causa de un panic es
capturar un "crash dump", usando <tt/gdb(1)/ para hacer una traza del
"crash dump". Por supuesto, esto depende de que <tt/gdb(1)/ funcione
correctamente en -current, lo que no puedo garantizar (recuerdo que
alguien ha comentado que el nuevo <tt/gdb(1)/ en formato ELF no
manejaba bién los "dumps" de un crash del kernel; alguién
debería mirar esto antes de que la 3.0 salga del estado beta).
<p>En cualquier caso, el método que normalmente uso es este:
<itemize>
<item>Crear un fichero de configuración de kernel, opcionalmente
añadiendo 'options DDB' si piensas que necesitas el debugger
del kernel por algún motivo. (Uso esto principalmente para
configurar puntos de salida si sospecho que existe alguna
condición que crea un loop infinito).
<item>Usar <tt/config -g KERNELCONFIG/ para crear el directorio
de configuración del kernel.
<item><tt>cd /sys/compile/KERNELCONFIG; make</tt>
<item>Esperar a que el kernel termine de compilar.
<item><tt/cp kernel kernel.debug/
<item><tt/strip -d kernel/
<item><tt/mv /kernel /kernel.orig/
<item><tt>cp kernel /</tt>
<item>reboot
</itemize>
<p><em>[Nota: ahora que los kernels de FreeBSD 3.x son ELF por defecto
debes usar <tt/strip -g/ en lugar de <tt/strip -d/. Si por algún
motivo tu kernel es aún a.out, usa <tt/strip -aout -d/.]</em>
<p>Ten en cuenta que TU <em/NO/ QUIERES ARRANCAR CON UN KERNEL QUE TIENE
TODOS LOS SIMBOLOS DE DEBUG EN EL. Un kernel compilado con <tt/-g/
puede llegar facilmente a los 10MB de tamaño. No tienes que
arrancar esta imán masiva, solo lo necesitas para poder usar
después <tt/gdb(1)/ (<tt/gdb(1)/ quiere la tabla de
símbolos). Al contrario, quieres mantener una copia de la
imágen completa y crear una segunda imágen con los
símbolos de debug desactivados usando <tt/strip -d/. Es esta
segunda imágen la que quieres arrancar.
<p>Para asegurarte de capturar un "crash dump", necesitas editar el
fichero <tt>/etc/rc.conf</tt> y apuntar <tt/dumpdev/ a tu
partición de swap. Esto hará que el script <tt/rc(8)/ use
el comando <tt/dumpon(8)/ para activar los "crash dumps". También
puedes ejecutar manualmente <tt/dumpon(8)/. Después de un panic,
el "crash dump" puede ser recuperado usando <tt/savecore(8)/; si
<tt/dumpdev/ está en <tt>/etc/rc.conf</tt>, el script
<tt/rc(8)/ ejecutará <tt/savecore(8)/ automaticamente y
pondrá el "crash dump" en <tt>/var/crash</tt>.
<p>NOTA: los "crash dumps" de FreeBSD suelen tener el mismo
tamaño que la cantidad total de memoria física del
sistema. Esto significa que si tienes 64MB de RAM, obtendrás
un "crash dump" de 64MB. Debido a esto, tienes que asegurarte de tener
suficiente espacio libre en <tt>/var/crash</tt>. Alternativamente puedes
ejecutar <tt/savecore(8)/ manualmente y hacer la recuparación en
otro directorio donde tengas más espacio libre. Es posible
limitar el tamaño del "crash dump" usando <tt/options MAXMEM=(foo)/
para indicar la cantidad de memoria que el kernel puede ocupar. Por
ejemplo, si tienes 128MB de RAM, puedes limitar el uso de memoria del
kernel a 16MB para que el "crash dump" sea de 16MB y no de 128MB.
<p>Una vez hayas recuperado el "crash dump", puedes obtener una traza
del stack con <tt/gdb(1)/ de la manera siguiente:
<p>
<verb>
% gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0
(gdb) where
</verb>
<p>Es posible que aparezcan muchas líneas de información:
es una buena idea usar el comando <tt/script(1)/ para capturarlas
todas. Usando la imágen del kernel con todos los símbolos
de debug deberí mostrar la línea exacta de código
fuente del kernel donde ha ocurrido el panic. Normalmente, tienes que
leer la traza del stack de abajo hacia arriba para poder conocer la
secuencia exacta de eventos que han provocado el crash. También
puedes usar <tt/gdb(1)/ para mostrar los contenidos de las diferentes
variables o estructuras para examinar el estado del sistema en el
momento del crash.
<p>Ahora, si eres realmente curioso y tienes un segundo ordenador,
puedes configurar <tt/gdb(1)/ para hacer un debug remoto de manera
que puedes usar <tt/gdb(1)/ en un sistema para revisar el kernel
de otro sistema, de la misma manera que lo harías en la
máquina local.
<p><em>[Bill añade: "Olvidé mencionar una cosa: si tienes
DDB activado, puedes forzar un panic (y un crash dump) tecleando
"panic" en el prompt del ddb. Es posible que el debugger se pare
durante la fase del panic. Si esto ocurre, teclea "continue" y el
crash dump finalizará"]</em>
<sect1>
<heading>dlsym() no funciona con ejecutables ELF!</heading>
<p>Las herramientas ELF no hacen por defecto que los símbolos
definidos en un ejecutable sean visibles por el linker dinámico.
Consecuentemente, <tt/dlsym()/ buscará en datos obtenidos desde
llamadas a <tt>dlopen(NULL, flags)</tt>, lo que provoca que no se
encuentren esos símbolos.
<p>Si quieres buscar, usando <tt/dlsym()/ símbolos presentes
en el ejecutable principal de un proceso, necesitas linkar el
ejecutable usando la opción <tt>-export-dynamic</tt> en el
<htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?ld"
name="linkador ELF">.
<sect1>
<heading>Incrementando o reduciendo el espacio de direcciones del
kernel</heading>
<p>Por defecto, el espacio de direcciones del kernel es de 256MB en
FreeBSD 3.x y 1GB en FreeBSD 4.x. Si gestionas un servidor de red
muy cargado (por ejemplo, servidores FTP o HTTP con mucho
tráfico), es posible que notes que 256MB no es
suficiente.
<p>Así que... como incremento el espacio de direcciones?. Hay
dos aspectos a tener en cuenta. Primero, necesitas indicarle al kernel
que reserve una mayor parte del espacio de direcciones para él
mismo. Segundo, ya que el kernel se carga al inicio del espacio de
direcciones, necesitas disminuir la dirección de carga.
<p>El primer aspecto lo solucionamos incrementando el valor de
<tt/NKPDE/ en <tt>src/sys/i386/include/pmap.h</tt>. Esta es una entrada
de ejemplo para 1GB de espacio de direcciones:
<verb>
#ifndef NKPDE
#ifdef SMP
#define NKPDE 254 /* addressable number of page tables/pde's */
#else
#define NKPDE 255 /* addressable number of page tables/pde's */
#endif /* SMP */
#endif
</verb>
<p>Para encontrar el valor correcto de <tt/NKPDE/, divide el espacio de
direcciones deseado (en megabytes) por cuatro, después resta uno
por UP y dos por SMP.
<p>Para solucionar el segundo aspecto, necesitas calcular la
dirección correcta de carga: simplemente resta el tamaño
del espacio de direcciones (en bytes) de 0x100100000; el resultado
es 0xc0100000 para 1GB de espacio de direcciones. Ajusta
<tt/LOAD_ADDRESS/ en <tt>src/sys/i386/conf/Makefile.i386</tt> a ese
valor; a continuación pon el contador al inicio de la
sección listado en <tt>src/sys/i386/conf/kernel.script</tt>
al mismo valor, como sigue:
<verb>
OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(btext)
SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/obj/elf/home/src/tmp/usr/i386-unknown-FreeBSDelf/lib);
SECTIONS
{
/* Read-only sections, merged into text segment: */
. = 0xc0100000 + SIZEOF_HEADERS;
.interp : { *(.interp) }
</verb>
<p>Reconfigura y compila el kernel. Probablemente tengas problemas con
<tt/top(1)/, <tt/ps(1)/ y programas así; haciendo un
<tt/make world/ deberín solucionarse esos problemas (o una
recompilación manual de <tt/libkvm/, <tt/ps/ y <tt/top/
después de copiar el <tt/pmap.h/ parcheado a
<tt>/usr/include/vm/</tt>.
<p>NOTA: el tamaño del espacio de direcciones debe ser un
múltiplo de cuatro megabytes.
<p><em>[<url url="mailto:dg@FreeBSD.org" name="David Greenman">
añade: </em>Pienso que el espacio de direcciones del kernel
necesita ser una potencia de 2, pero no estoy totalmente seguro.]
</sect>
|