Introducciónalos sistemasoperativos:uso delproyectoOpenSolarisprofesores.fi-b.unam.mx/sun/Downloads/Solaris/OpenSolaris... · 2018-07-12 · Introducciónalos sistemasoperativos:uso

Introducción a lossistemas operativos: usodel proyecto OpenSolarisGuía del estudiante

Sun Microsystems, Inc.4150 Network CircleSanta Clara, CA 95054U.S.A.

Copyright 2007 Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, CA 95054 U.S.A. Reservados todoslos derechos.

Sun Microsystems, Inc. posee derechos de propiedad intelectual en relación con la tecnología incluida en el productodescrito en este documento. De forma específica y sin limitación, entre estos derechos de propiedad intelectual seincluyen una o varias patentes en los EE.UU. o aplicaciones pendientes de patente en los EE.UU. y otros países.

Derechos gubernamentales de los EE. UU. – Software comercial. Los usuarios gubernamentales están sujetos alacuerdo de licencia estándar de Sun Microsystems, Inc. y a las disposiciones aplicables de la regulación FAR y sussuplementos.

Esta distribución puede incluir materiales desarrollados por terceras partes.

Determinadas partes del producto pueden derivarse de Berkeley BSD Systems, con licencia de la Universidad deCalifornia. UNIX es una marca registrada en los EE.UU. y otros países, bajo licencia exclusiva de X/Open Company,Ltd.

Sun, Sun Microsystems, el logotipo de Sun, el logotipo de Solaris, el logotipo de la taza de café de Java, docs.sun.com,Java y Solaris son marcas comerciales o marcas comerciales registradas de Sun Microsystems, Inc. en EE.UU y otrospaíses. Todas las marcas registradas SPARC se usan bajo licencia y son marcas comerciales o marcas registradas deSPARC International, Inc. en los EE.UU. y en otros países. Los productos con las marcas registradas de SPARC sebasan en una arquitectura desarrollada por Sun Microsystems, Inc.

La interfaz gráfica de usuario OPEN LOOK y SunTM fue desarrollada por Sun Microsystems, Inc. para sus usuarios ylicenciatarios. Sun reconoce los esfuerzos pioneros de Xerox en la investigación y desarrollo del concepto deinterfaces gráficas o visuales de usuario para el sector informático. Sun dispone de una licencia no exclusiva de Xeroxpara la interfaz gráfica de usuario de Xerox, que también cubre a los licenciatarios de Sun que implementen las GUIde OPEN LOOK y que, por otra parte, cumplan con los acuerdos de licencia por escrito de Sun.

Los productos descritos y abordados en esta publicación están sometidos a la legislación de control de exportacionesde los EE.UU. y pueden estar sujetos a leyes de importación o exportación de otros países. Se prohíbe estrictamente eluso final de estos productos en misiles nucleares, armas químicas o biológicas o aplicaciones nucleares marítimas, yasea de forma directa o indirecta. Se prohíbe estrictamente la exportación o reexportación a países bajo el embargo delos EE.UU o a entidades incluidas en la lista de exclusión de exportación de los EE.UU., incluidas, pero nolimitándose a, las personas rechazadas y a las listas nacionales designadas específicamente.

ESTA DOCUMENTACIÓN SE PROPORCIONA “TAL CUAL”. SE RENUNCIA A TODAS LAS CONDICIONESEXPRESAS O IMPLÍCITAS, REPRESENTACIONES Y GARANTÍAS, INCLUIDAS CUALQUIER GARANTÍAIMPLÍCITA DE COMERCIALIZACIÓN, ADECUACIÓN PARA UNA FINALIDAD DETERMINADA O DE NOCONTRAVENCIÓN, EXCEPTO EN AQUELLOS CASOS EN QUE DICHA RENUNCIA NO FUERALEGALMENTE VÁLIDA.

Copyright 2007 Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, CA 95054 U.S.A. Tous droitsréservés.

Sun Microsystems, Inc. détient les droits de propriété intellectuelle relatifs à la technologie incorporée dans le produitqui est décrit dans ce document. En particulier, et ce sans limitation, ces droits de propriété intellectuelle peuventinclure un ou plusieurs brevets américains ou des applications de brevet en attente aux Etats-Unis et dans d'autrespays.

Cette distribution peut comprendre des composants développés par des tierces personnes.

Certaines composants de ce produit peuvent être dérivées du logiciel Berkeley BSD, licenciés par l'Université deCalifornie. UNIX est une marque déposée aux Etats-Unis et dans d'autres pays; elle est licenciée exclusivement parX/Open Company, Ltd.

Sun, Sun Microsystems, le logo Sun, le logo Solaris, le logo Java Coffee Cup, docs.sun.com, Java et Solaris sont desmarques de fabrique ou des marques déposées de Sun Microsystems, Inc. aux Etats-Unis et dans d'autres pays. Toutesles marques SPARC sont utilisées sous licence et sont des marques de fabrique ou des marques déposées de SPARCInternational, Inc. aux Etats-Unis et dans d'autres pays. Les produits portant les marques SPARC sont basés sur unearchitecture développée par Sun Microsystems, Inc.

L'interface d'utilisation graphique OPEN LOOK et Sun a été développée par Sun Microsystems, Inc. pour sesutilisateurs et licenciés. Sun reconnaît les efforts de pionniers de Xerox pour la recherche et le développement duconcept des interfaces d'utilisation visuelle ou graphique pour l'industrie de l'informatique. Sun détient une licence

non exclusive de Xerox sur l'interface d'utilisation graphique Xerox, cette licence couvrant également les licenciés deSun qui mettent en place l'interface d'utilisation graphique OPEN LOOK et qui, en outre, se conforment aux licencesécrites de Sun.

Les produits qui font l'objet de cette publication et les informations qu'il contient sont régis par la legislationaméricaine en matière de contrôle des exportations et peuvent être soumis au droit d'autres pays dans le domaine desexportations et importations. Les utilisations finales, ou utilisateurs finaux, pour des armes nucléaires, des missiles,des armes chimiques ou biologiques ou pour le nucléaire maritime, directement ou indirectement, sont strictementinterdites. Les exportations ou réexportations vers des pays sous embargo des Etats-Unis, ou vers des entités figurantsur les listes d'exclusion d'exportation américaines, y compris, mais de manière non exclusive, la liste de personnesqui font objet d'un ordre de ne pas participer, d'une façon directe ou indirecte, aux exportations des produits ou desservices qui sont régis par la legislation américaine en matière de contrôle des exportations et la liste de ressortissantsspécifiquement designés, sont rigoureusement interdites.

LA DOCUMENTATION EST FOURNIE "EN L'ETAT" ET TOUTES AUTRES CONDITIONS, DECLARATIONSET GARANTIES EXPRESSES OU TACITES SONT FORMELLEMENT EXCLUES, DANS LA MESUREAUTORISEE PAR LA LOI APPLICABLE, Y COMPRIS NOTAMMENT TOUTE GARANTIE IMPLICITERELATIVE A LA QUALITE MARCHANDE, A L'APTITUDE A UNE UTILISATION PARTICULIERE OU AL'ABSENCE DE CONTREFACON.

Contenido

1 ¿Qué es el proyecto OpenSolaris? ..................................................... 9Portales de países ............................................................................... 12Recursos Web para OpenSolaris ..................................................... 13Debates ............................................................................................... 13Comunidades ..................................................................................... 13Proyectos ............................................................................................ 15Depósitos de origen ........................................................................... 16OpenGrok .......................................................................................... 16

2 Impulsores de OpenSolaris ..............................................................19¿Por qué se recomienda el uso de OpenSolaris? ............................. 20Precio .................................................................................................. 20Funciones principales innovadoras ................................................ 21Compatibilidad con versiones anteriores ....................................... 21Plataforma de hardware neutra ....................................................... 22Herramientas de desarrollo .............................................................. 23Agradecimientos ............................................................................... 25

3 Planificación del entorno de OpenSolaris ..................................... 27Configuración del entorno de desarrollo ....................................... 29Redes ................................................................................................... 32

5

Daemon de configuración automática de red ........................... 33Descripción general de zona ....................................................... 34Administración de zonas ............................................................. 35

Introducción a la administración de zonas ........................ 36Virtualización del servidor Web con zonas ............................... 40

Creación de zonas no globales ............................................. 41Creación de agrupaciones de almacenamiento ZFS y sistemasde archivos ..................................................................................... 46Creación de agrupaciones de almacenamiento ZFSduplicadas ...................................................................................... 47Creación de sistemas de archivos ZFS como directorios deinicio .............................................................................................. 49Creación de una configuración RAID-Z ................................... 52

4 Consolidaciones de userland ......................................................55Consolidaciones userland y descripciones ................................ 56

5 Características principales del sistema operativo Solaris ..... 59Proceso de desarrollo y estilo de código .................................... 60Información general ..................................................................... 64FireEngine ..................................................................................... 64Minimización de los privilegios .................................................. 67Filtros de paquetes ........................................................................ 68Zonas .............................................................................................. 71Zonas de marca (BrandZ) ............................................................ 73Redes de zonas .............................................................................. 74Recuperación automática predecible ......................................... 77Dynamic Tracing (DTrace) ......................................................... 78Modular Debugger (MDB) ......................................................... 79

Contenido

Introducción a los sistemas operativos: uso del proyecto OpenSolaris •Septiembre de 2007

6

Sistema de archivos ZFS .............................................................. 80Utilidad de gestión de servicios (SMF) ...................................... 81

6 Conceptos de programación ......................................................83Administración del sistema y los procesos ................................ 84Programación de subprocesos .................................................... 85Planificación de la CPU ............................................................... 88Descripción general del núcleo ................................................... 92Depuración de procesos .............................................................. 95

7 Introducción a DTrace ..................................................................99Activación de sondeos DTrace sencillos .................................. 100Enumeración de sondeos rastreables ....................................... 103Programación en D .................................................................... 107

8 Depuración de aplicaciones con DTrace .................................111Activación de los sondeos en modo de usuario ...................... 112

Uso de DTrace con aplicaciones ....................................... 113

9 Depuración de aplicaciones C++ con DTrace .........................119Uso de DTrace para perfilar y depurar un programa en C++ 120

10 Gestión de memoria con DTrace y MDB .................................. 133Gestión de memoria del software ............................................. 134Uso de DTrace y MDB para examinar la memoria virtual .... 135

Contenido

7

11 Depuración de controladores con DTrace ..............................149Asignación de puertos al controlador smbfs de Linux al sistemaoperativo Solaris ......................................................................... 150

A Recursos de OpenSolaris ...........................................................161

Contenido


8

¿Qué es el proyecto OpenSolaris?

ObjetivosEl objetivo de este curso es conocer el funcionamiento de unsistema operativo utilizando el código fuente del sistema operativoSolarisTM, disponible de forma gratuita a través del proyectoOpenSolaris.

Consejo – Para recibir un paquete de inicio de OpenSolaris gratuitoque incluya el material de formación, el código fuente y lasherramientas de desarrollo, regístrese en línea en la páginahttp://get.opensolaris.org.

Empezaremos describiendo los grupos de usuarios, los portales yla documentación que necesitará para familiarizarse con UNIX®. Acontinuación, le indicaremos cómo acceder al código, lascomunidades, los debates, los proyectos y el navegador de códigodel proyecto OpenSolaris. Le señalaremos los pasos necesariospara configurar las zonas, ZFS, las redes y el entorno. Por último,mostraremos los procesos de depuración, las aplicaciones, loserrores de páginas y los controladores de dispositivos con DTraceen los ejercicios prácticos.

El proyecto OpenSolaris se inició el 14 de junio de 2005 para aunarlos esfuerzos de desarrollo de la comunidad tomando como puntode partida el código del sistema operativo Solaris. Se trata de un

1M Ó D U L O 1

9

nexo para el desarrollo de la comunidad, donde colaboradoresde Sun y otros lugares pueden contribuir al desarrollo y lamejora de la tecnología de sistema operativo. El código fuentede OpenSolaris puede tener múltiples usos, por ejemploconstituir la base de futuras versiones del sistema operativoSolaris, otros proyectos de sistema operativo, y distribuciones yproductos de terceros que puedan ser de interés para lacomunidad. El proyecto OpenSolaris está patrocinadoactualmente por Sun Microsystems, Inc.

Durante los dos primeros años, más de 60.000 participantes sehan registrado como miembros. La comunidad de ingenierosno para de aumentar y cambiar para satisfacer las necesidadesde los desarrolladores, los administradores de sistemas y losusuarios finales del sistema operativo Solaris.

La formación con el proyecto OpenSolaris proporciona lasventajas siguientes con respecto a los sistemas operativos deformación:■ Acceso al código para las innovadoras tecnologías del

sistema operativo Solaris 10■ Acceso al código para un sistema operativo comercial que se

utilice en varios entornos y se pueda escalar a sistemas másgrandes

■ Herramientas superiores de depuración y observación■ Compatibilidad con plataforma de hardware que incluye las

arquitecturas SPARC, x86 y x64■ Liderazgo en funcionamiento de 64 bits■ Derechos de uso ilimitados y gratuitos■ Base de código libre, innovadora, emocionante, completa,

sólida e integral■ La disponibilidad bajo la licencia CDDL (Common

Development and Distribution License o Desarrollo comúny licencia de distribución) aprobada por la Open Source



10

Initiative (OSI) permite usar sin derechos de autor, realizarmodificaciones y llevar a cabo trabajos derivados


Módulo 1 • ¿Qué es el proyecto OpenSolaris? 11

Portales de paísesLa Internationalization and Localization Community estácontribuyendo a la traducción de la página Web en inglés deOpenSolaris a múltiples idiomas. Hasta la fecha, se estándesarrollando los portales de ocho países:

■ Portal de India: http://in.opensolaris.org■ Portal de China: http://cn.opensolaris.org■ Portal de Japón: http://jp.opensolaris.org■ Portal de Polonia: http://pl.opensolaris.org■ Portal de Francia: http://fr.opensolaris.org■ Portal de Brasil: http://opensolaris.org/os/project/br■ Portal de España:

http://opensolaris.org/os/project/es

Está previsto el desarrollo de los portales de Alemania, Rusia,República Checa, España, Corea y México. Consulte losportales del proyecto OpenSolaris para participar o charlar enuna de las siete salas de charla de OpenSolaris utilizando IRC enirc.freenode.net. Consultehttp://opensolaris.org/os/chat/.

Portales de países


12

http://in.opensolaris.org

http://cn.opensolaris.org

http://jp.opensolaris.org

http://pl.opensolaris.org

http://fr.opensolaris.org

http://opensolaris.org/os/project/br

http://opensolaris.org/os/project/es

http://opensolaris.org/os/chat/

Recursos Web para OpenSolarisPuede descargar la fuente de OpenSolaris, ver los términos de lalicencia y acceder a instrucciones sobre cómo crear código einstalar los archivos previamente configurados en:http://www.opensolaris.org/os/downloads.

Los iconos de la parte superior derecha de las páginas Web deOpenSolaris son vínculos a debates, comunidades, proyectos,descargas y recursos de navegador de código.

Además, la página Web de OpenSolaris permite buscarcontenido en todo el sitio y en los blogs agregados.

DebatesLos debates permiten entrar en contacto con los expertos quetrabajan en nuevas tecnologías de código abierto. Asimismo,incluyen un archivo de las conversaciones anteriores que puedeconsultar para dar respuesta a sus preguntas. Consultehttp://www.opensolaris.org/os/discussions para ver unalista completa de los foros a los que se puede suscribir.

ComunidadesLas comunidades permiten contactar con otros participantescon intereses similares en el proyecto OpenSolaris. Secomponen de grupos de interés, tecnologías, soporte,herramientas y grupos de usuarios, como:

Teoría einvestigación

http://www.opensolaris.org/os/community/edu

Recursos Web para OpenSolaris


http://www.opensolaris.org/os/community/edu

DTrace http://www.opensolaris.org/

os/community/dtrace

ZFS http://www.opensolaris.org/os/community/zfs

Redes http://www.opensolaris.org/

os/community/networking

Zonas http://www.opensolaris.org/os/community/zones

Documentación http://www.opensolaris.org/

os/community/documentation

Controladoresde dispositivos

http://www.opensolaris.org/

os/community/device_drivers

Herramientas http://www.opensolaris.org/os/community/tools

Impulsores http://www.opensolaris.org/

os/community/advocacy

Seguridad http://www.opensolaris.org/

os/community/security

Rendimiento http://www.opensolaris.org/

os/community/performance

Almacenamiento http://www.opensolaris.org/

os/community/storage

Administradoresde sistemas


os/community/sysadmin

Éstas son sólo algunas de las 30 comunidades que trabajan deforma activa en OpenSolaris. Consultehttp://www.opensolaris.org/os/communities para ver lalista completa.



14

http://www.opensolaris.org/os/community/dtrace

http://www.opensolaris.org/os/community/dtrace

http://www.opensolaris.org/os/community/zfs

http://www.opensolaris.org/os/community/networking


http://www.opensolaris.org/os/community/zones

http://www.opensolaris.org/os/community/documentation

http://www.opensolaris.org/os/community/documentation

http://www.opensolaris.org/os/community/device_drivers

http://www.opensolaris.org/os/community/device_drivers

http://www.opensolaris.org/os/community/tools

http://www.opensolaris.org/os/community/advocacy

http://www.opensolaris.org/os/community/advocacy

http://www.opensolaris.org/os/community/security

http://www.opensolaris.org/os/community/security

http://www.opensolaris.org/os/community/performance

http://www.opensolaris.org/os/community/performance

http://www.opensolaris.org/os/community/storage

http://www.opensolaris.org/os/community/storage

http://www.opensolaris.org/os/community/sysadmin

http://www.opensolaris.org/os/community/sysadmin

http://www.opensolaris.org/os/communities

ProyectosLos proyectos alojados en la página Webhttp://www.opensolaris.org/ reúnen aportaciones quegeneran, por ejemplo, cambios de código, documentos, gráficoso productos de varios autores. Los proyectos cuentan condepósitos de código y "committers", y pueden existir dentro deuna comunidad o de forma independiente.

Los participantes inician nuevos proyectos a partir de laspeticiones que los usuarios efectúan en los debates. Losproyectos que se envían consiguen espacio en la página deproyectos para poder iniciarse siempre que lo acepte al menosun participante interesado de la comunidad patrocinadora queno sea el "commiter". Consultehttp://www.opensolaris.org/os/projects para ver la listaactual de proyectos nuevos.

Herramienta devisualizaciónChime paraDTrace


os/project/dtrace-chime

Google Summerof Code

http://www.opensolaris.org/os/project/powerPC

Indiana http://www.opensolaris.org/os/project/indiana

OpenGrok http://www.opensolaris.org/

os/project/opengrok

Concurso deprogramación

http://www.opensolaris.org/os/project/contest

Paquete deinicio


os/project/starterkit

Destino iSCSIde Solaris


os/project/iscsitgt




http://www.opensolaris.org/os/projects

http://www.opensolaris.org/os/project/dtrace-chime

http://www.opensolaris.org/os/project/dtrace-chime

http://www.opensolaris.org/os/project/powerPC

http://www.opensolaris.org/os/project/indiana

http://www.opensolaris.org/os/project/opengrok


http://www.opensolaris.org/os/project/contest

http://www.opensolaris.org/os/project/starterkit

http://www.opensolaris.org/os/project/starterkit

http://www.opensolaris.org/os/project/iscsitgt

http://www.opensolaris.org/os/project/iscsitgt

Depósitos de origenLos depósitos de origen centralizados y distribuidos se alojan enel sitio Web opensolaris.org. El modelo de administración deorígenes centralizados utiliza el programa de administración decontrol de origen Subversion (SVN). Los depósitosadministrados de forma distribuida utilizan el programa deadministración de control de origen Mercurial (hg).

Los responsables de proyectos de opensolaris.org utilizan laspáginas Web de proyectos para completar la creación de undepósito de origen. Los desarrolladores con derechos de envíoacceden a los depósitos a través de sus cuentas deopensolaris.org. Los responsables de proyectos se encargande administrar los derechos de envío. Si necesita una cuenta,puede registrarse para obtener una. Debe proporcionar unaclave pública Secure Shell (SSH). Consulte la comunidad deherramientas para conocer la información más reciente relativaal control de origen, acceder a descargas y obtenerinstrucciones(http://opensolaris.org/os/community/tools).

OpenGrokOpenGrokTM es el motor de búsqueda de código fuente yreferencias cruzadas de gran rapidez que se utiliza enOpenSolaris. Vaya a http://cvs.opensolaris.org/sourcepara probarlo.

OpenGrok fue el primer proyecto que se alojó enopensolaris.org. Consultehttp://www.opensolaris.org/os/project/opengrok paraobtener información sobre el proyecto de desarrollo actual.

Eche un vistazo al código fuente; descubrirá código claro y conamplios comentarios que se leen con gran facilidad. Si leinteresa trabajar en un proyecto de OpenSolaris, descargue el



16

http://opensolaris.org/os/community/tools

http://cvs.opensolaris.org/source


código base completo. Si sólo desea conocer el funcionamientode algunas opciones del sistema operativo Solaris, el navegadorde código fuente es de gran ayuda. OpenGrok admite variosformatos de archivos de programa e historiales de control deversiones como SCCS, RCS o CVS, de modo que facilita lacomprensión del código abierto.



18

Impulsores de OpenSolaris

ObjetivosLa comunidad de impulsores tiene la finalidad de promover laparticipación de personas de todo el mundo en la comunidadOpenSolaris. Agradecemos la participación de cualquier persona,independientemente de su idioma, cultura o nivel deconocimientos técnicos y no técnicos. Todo el mundo tiene algoque aportar.

Consulte http://opensolaris.org/os/community/advocacy/.

En la comunidad de impulsores, encontrará proyectos de gruposde usuarios independientes, así como presentaciones, noticias,artículos, blogs, contenido técnico y no técnico, vídeos y podcasts,eventos y conferencias, estadísticas de la comunidad,promociones, dispositivos y parches, botones y otros proyectospromocionales.

2M Ó D U L O 2

19

http://opensolaris.org/os/community/advocacy/

¿Por qué se recomienda el uso deOpenSolaris?

En esta sección se describen los motivos prácticos por los quedebe considerar el uso de OpenSolaris como plataforma dedesarrollo.

PrecioDesde el lanzamiento del sistema operativo Solaris 10 en enerode 2005, su popularidad ha crecido enormemente. A fecha dejulio de 2007, se registraron más de 8,7 millones de copias, unacifra superior a la suma de todas las versiones anteriores delsistema operativo Solaris. El lanzamiento de OpenSolaris enjunio de 2005 afianzó esta frenética tendencia. Debido a esteaumento repentino del número de usuarios, cada vez másdesarrolladores (tanto comerciales como de código abierto)consideran el sistema operativo Solaris como una soluciónviable para su software.

Uno de los motivos por los que el sistema operativo Solarisdisfrutó de un gran aumento de popularidad fue su precio: esgratuito para cualquier uso (tanto comercial como nocomercial) en cualquier equipo (en plataformas SPARC y x86).Otro motivo fue la promesa de Sun (y el cumplimiento de lamisma) de facilitar el código fuente de Solaris disponible conuna licencia de código abierto aprobada por la OSI, la licenciade distribución y desarrollo común o Common Developmentand Distribution License (CDDL).

¿Por qué se recomienda el uso de OpenSolaris?


20

Funciones principales innovadorasSin embargo, el motivo más importante de la popularidad de laque goza el sistema operativo Solaris es sin duda la ampliavariedad de funciones que ofrece. A continuación se incluyenalgunas de ellas, sin un orden específico:■ Zonas de Solaris: permiten particionar un equipo en

distintos equipos virtuales, cada uno de los cuales estáaislado del resto.

■ DTrace: completa herramienta de rastreo dinámico paraanalizar el comportamiento del sistema sin que ello afecte ala producción de los equipos.

■ Nueva pila IP: ofrece un rendimiento mejoradonotablemente.

■ ZFS: sistema de archivos de 128 bits de última generacióncon comprobación y corrección de errores, una interfaz delínea de comandos sencilla y una capacidad dealmacenamiento casi ilimitada.

Compatibilidad con versionesanterioresTodas estas funciones se basan en unos pilares que los usuarioshabituales del sistema operativo Solaris esperan encontrar:solidez y estabilidad, escalabilidad, elevado rendimiento ycompatibilidad con versiones anteriores garantizada. Lacompatibilidad con versiones anteriores resulta especialmenteimportante para los desarrolladores de software comercial, yaque el mantenimiento es normalmente el mayor gasto asociadoa cualquier software. Gracias a la garantía de compatibilidadcon versiones anteriores, los proveedores de software saben queel software creado para Solaris N (siempre que se utilicenúnicamente las API publicadas) se ejecutará correctamente en


Módulo 2 • Impulsores de OpenSolaris 21

las versiones Solaris N+1 y posteriores. Esto es una ventaja conrespecto a otros sistemas operativos, en los que se realizancambios incompatibles en los componentes del sistema (porejemplo, bibliotecas), sin importar el efecto que ello tenga en lasaplicaciones. Por ejemplo, si las aplicaciones se bloquean, segeneran más gastos de mantenimiento y la frustración deproveedores y usuarios.)

Plataforma de hardware neutraEn los párrafos anteriores se mencionan algunos motivos porlos que se debe desarrollar para el sistema operativo Solaris,pero existen motivos adicionales para desarrollar en laplataforma Solaris. Uno de ellos es que Solaris es un sistemaoperativo que sirve de plataforma para varios sistemasoperativos, y es compatible con arquitecturas SPARC y x86 (yademás se está desarrollando un puerto controlado por lacomunidad para Power). Aunque hace unos años hubo unproblema con el sistema operativo Solaris para las plataformasx86, el hecho de que Sun haya introducido una gama deestaciones de trabajo y servidores basados en AMD demuestrael compromiso de la compañía con la tecnología x86.

Desde el punto de vista de los desarrolladores, las versiones deSolaris para plataformas SPARC y x86 cuentan con los mismosgrupos de funciones y API. Gracias a ello, los desarrolladores sepueden centrar en otros problemas endémicos del desarrolloentre plataformas, como el formato de los bytes significativosde CPU. En la plataforma SPARC se incluyen primero los bytesmás significativos, y en la plataforma x86 se incluyen primerolos bytes menos significativos, de modo que es muy probableque una aplicación que se desarrolla y prueba en la plataformaSolaris plantee problemas relativos a los bytes significativos. Elsistema operativo Solaris también admite aplicaciones tanto de



22

32 como de 64 bits en ambas plataformas, con lo cual se ponefin a los problemas derivados de las suposiciones de tamaño depalabra.

Posiblemente el motivo más convincente para desarrollarsoftware en el sistema operativo Solaris sea la gran variedad deherramientas de desarrollo profesional que hay disponiblespara el mismo.

Herramientas de desarrolloUna de las características más importantes de un sistemaoperativo desde el punto de vista de un desarrollador es lavariedad y calidad de las herramientas de desarrollodisponibles. Los compiladores y depuradores son el ejemplomás obvio de estas herramientas, pero también se incluyencomprobadores de código (para asegurarse de que el código notenga pequeños errores que no detecte el compilador),generadores de referencias cruzadas (para ver qué funcioneshacen referencia a otras funciones y variables) y analizadoresdel rendimiento.

El paquete Sun Studio es el producto preferido de losdesarrolladores del sistema operativo Solaris. El software SunStudio, que se puede descargar gratuitamente en el sitio Webhttp://developers.sun.com, es un conjunto de herramientasy compiladores profesionales. Incluye los compiladores C, C++y FORTRAN, herramientas de análisis de código, un entornode desarrollo integrado (IDE), el depurador de nivel fuente dbxy editores. Otras herramientas que se incluyen con el softwareStudio son cscope (un examinador de código fuenteinteractivo), ctrace (una herramienta para generar una versiónde nuestros programas que se rastree automáticamente), cxref(un generador de referencias cruzadas de C), dmake (paramakes paralelos distribuidos) y lint (el comprobador delprograma C).



El sistema operativo Solaris se suministra con el compilador CGNU, gcc, y su correspondiente depurador de nivel fuente, gdb.Además, incluye el potente depurador modular mdb. Sinembargo, mdb no es un depurador de nivel fuente. Resulta másútil cuando se depura código del núcleo, o cuando se llevan acabo análisis al final del proyecto en programas para los que nohay código fuente disponible. Consulte Solaris ModularDebugger Guide y Solaris Performance and Tools deMcDougall, Mauro y Gregg para obtener información adicionalsobre mdb.



24

AgradecimientosLos siguientes miembros de la comunidad OpenSolaris hanrevisado y comentado este documento:

■ Boyd Adamson■ Pradhap Devarajan■ Alan Coopersmith■ Brian Gupta■ Rainer Heilke■ Eric Lowe■ Ben Rockwood■ Cindy Swearingen

Los siguientes miembros de la comunidad OpenSolaris hanaportado nuevo contenido de calidad excelente:

■ Dong-Hai Han■ Narayana Janga■ Shivani Khosa■ Rich Teer■ Sunay Tripathi■ Yifan Xu

Nuestro agradecimiento también a Steven Cogorno, DavidComay, Teresa Giacomini, Stephen Hahn, Patrick Finch y SueWeber por su trabajo para hacer posible la versión inicial.

Para participar en futuras revisiones de este documento, siga lasinstrucciones de esta dirección URL:


os/community/documentation/reviews

Agradecimientos


http://www.opensolaris.org/os/community/documentation/reviews

http://www.opensolaris.org/os/community/documentation/reviews

26

Planificación del entorno deOpenSolaris

ObjetivosEl objetivo de este módulo es comprender los requisitos delsistema, la información de compatibilidad y la documentacióndisponible para la instalación y configuración del proyectoOpenSolaris.

Recursos adicionales■ Solaris Express Developer Edition Installation Guide: Laptop

Installations. Sun Microsystems, Inc., 2007.■ Recursos para ejecutar el sistema operativo Solaris en un

portátil:http://www.sun.com/

bigadmin/features/articles/laptop_resources.html

■ Comunidad de OpenSolaris para portátiles:http://opensolaris.org/os/community/laptop

■ Paquete de inicio de OpenSolaris:http://opensolaris.org/os/project/starterkit

■ System Administration Guide: IP Services, Sun Microsystems,Inc., 2007

■ Comunidad de redes de OpenSolaris:http://www.opensolaris.org/os/community/networking

3M Ó D U L O 3

27

http://www.sun.com/bigadmin/features/articles/laptop_resources.html

http://www.sun.com/bigadmin/features/articles/laptop_resources.html

http://opensolaris.org/os/community/laptop

http://opensolaris.org/os/project/starterkit


■ ZFS Administration Guide y páginas del comando man:http://opensolaris.org/os/community/zfs/docs

Planificación del entorno de OpenSolaris


28

http://opensolaris.org/os/community/zfs/docs

Configuración del entorno de desarrolloNada mejor que la experiencia y la práctica con código desistema operativo y acceso directo a los módulos de núcleo. Losdesafíos exclusivos del desarrollo de núcleos y el acceso a losprivilegios root de un sistema resultan más sencillos gracias aluso de las herramientas, los foros y la documentacióndisponibles para el proyecto OpenSolaris.

Consejo – Para recibir un paquete de inicio de OpenSolaris queincluya el material de formación, el código fuente y lasherramientas de desarrollo, vaya ahttp://get.opensolaris.org.

Tenga en cuenta los siguientes aspectos de OpenSolaris cuandoplanifique su entorno de desarrollo:

TABLA 3–1 Compatibilidad con componentes configurables

Componenteconfigurable Compatibilidad del proyecto OpenSolaris

Hardware OpenSolaris admite sistemas que utilizan las familias dearquitecturas de procesadorSPARC® y x86:UltraSPARC®, SPARC64, AMD64, Pentium y XeonEM64T. Para conocer los sistemas compatibles,consulte la lista de compatibilidad de hardware deSolaris en http://www.sun.com/bigadmin/hcl.

Archivos deorigen

Consulte http://opensolaris.org/os/downloadspara obtener instrucciones detalladas sobre cómogenerar a partir del origen.

Configuración del entorno de desarrollo

Módulo 3 • Planificación del entorno de OpenSolaris 29

http://get.opensolaris.org

http://www.sun.com/bigadmin/hcl

http://opensolaris.org/os/downloads

TABLA 3–1 Compatibilidad con componentes configurables(Continuación)


Imágenes deinstalación

Las distribuciones de OpenSolaris generadaspreviamente se limitan a Solaris Express: CommunityEdition [versión en DVD], versión 32 o posterior,Solaris Express: Developer Edition, Nexenta, Schillix,Martux y Belenix.

Para el núcleo de OpenSolaris con el entorno de usuarioGNU, vaya ahttp://www.gnusolaris.org/gswiki/Download-form.

Archivos BFU Se proporciona el archivoon-bfu-DATE.PLATFORM.tar.bz2 si se está instalandodesde archivos generados previamente.

Herramientasde generación

Se proporciona el archivoSUNWonbld-DATE.PLATFORM.tar.bz2 si se genera desdeel origen.

Compiladoresy herramientas

Los compiladores y las herramientas de Sun Studio 11están disponibles de forma gratuita para losdesarrolladores de OpenSolaris. Consultehttp://www.opensolaris.org/

os/community/tools/sun_studio_tools/ paraobtener instrucciones sobre cómo descargar e instalarlas versiones más recientes. Consulte tambiénhttp://www.opensolaris.org/

os/community/tools/gcc para acceder a la comunidadgcc.

Requisitos dememoria ydisco

■ Memoria necesaria: 256 MB mínimo (sóloinstalador de texto), 1 GB recomendado

■ Requisito de memoria: 768 MB mínimo para elinstalador de Solaris Express Developer Edition.

■ Espacio en el disco necesario: 350 MB.



30

http://www.gnusolaris.org/gswiki/Download-form

http://www.opensolaris.org/os/community/tools/sun_studio_tools/

http://www.opensolaris.org/os/community/tools/sun_studio_tools/

http://www.opensolaris.org/os/community/tools/gcc

http://www.opensolaris.org/os/community/tools/gcc

TABLA 3–1 Compatibilidad con componentes configurables(Continuación)


Entornos desistemaoperativovirtuales

Las zonas y zonas de marca en OpenSolarisproporcionan entornos de sistema operativo protegidosy virtualizados en una instancia de Solaris. Eso permitela ejecución de uno o más procesos de forma aislada deotra actividad del sistema.

OpenSolaris admite Xen, un monitor de máquinavirtual de código abierto desarrollado por el laboratoriode Informática de la Universidad de Cambridge.Consultehttp://www.opensolaris.org/os/community/xen/

para obtener más detalles y vínculos al proyecto Xen.

OpenSolaris también es un invitado de VMWareTM.Consultehttp://www.opensolaris.org/os/project/content

para ver un artículo reciente de introducción.

Consulte el Módulo 4 para obtener más información sobre elmodo en que las zonas y las zonas de marca permiten el núcleoy el desarrollo del modo de usuario de las aplicaciones Solaris yLinux sin repercutir en el trabajo de los desarrolladores en otraszonas.

La participación en el proyecto OpenSolaris puede mejorar elrendimiento global de la red con las tecnologías másinnovadoras. El entorno de trabajo se convierte enautosuficiente cuando se aloja en OpenSolaris porque siemprese ejecuta el mejor entorno y más reciente, y se le da laposibilidad de actualizarlo usted mismo.



http://www.opensolaris.org/os/community/xen/

http://www.opensolaris.org/os/project/content

RedesEl proyecto OpenSolaris satisface los futuros requisitos de lasredes al mejorar radicalmente el rendimiento de las mismas sinnecesidad de efectuar cambios en las aplicaciones.

■ Acelera el rendimiento de la aplicación en un 50 por cientogracias al uso de una pila TCP/IP mejorada

■ Admite muchas de las recientes tecnologías de redes, como10 Gigabit Ethernet, redes inalámbricas y transferencia dehardware

■ Admite flujo de datos de alta disponibilidad y funciones deredes de Voz sobre IP (VoIP) gracias a la compatibilidadcon protocolos y rutas extendidas

■ Admite las especificaciones IPv6 actuales

En la dirección siguiente encontrará más información sobre losdesarrollos de red actuales de la comunidad de redes deOpenSolaris:http://www.opensolaris.org/os/community/networking.



32


Daemon de configuración automática dered

El proceso de arranque de Solaris Express Developer Edition5/07 ejecuta el daemon nwamd. Este daemon implementa unainstancia alternativa del servicio SMF,svc:/network/physical, lo que permite una configuración dered automatizada con una intervención mínima.

El daemon nwamd supervisa el puerto Ethernet y admite DHCPautomáticamente en la interfaz IP pertinente. Si no hay ningúncable conectado a la red con cables, el daemon nwamd lleva acabo una exploración inalámbrica y envía consultas al usuariopara obtener un punto de acceso WiFi al que conectarse.

No es necesario dedicar una gran cantidad de tiempo aconfigurar manualmente las interfaces de los sistemas. Laconfiguración automática también es útil para laadministración, ya que puede reconfigurar las direcciones dered con una intervención mínima.

Para ver el estado de NWAM, escriba el comando siguiente enuna ventana de terminal.

# svcs nwam

STATE STIME FMRI

online 11:29:50 svc:/network/physical:nwam

La página de OpenSolaris Network Auto-Magic Phase 0 y lapágina del comando man nwamd contienen más detalles, comolas instrucciones para desactivar el daemon nwamd, en caso deque desee hacerlo. Para obtener información adicional y unvínculo a la página del comando man nwamd(1M), consultehttp://www.opensolaris.org/os/project/nwam.

Daemon de configuración automática de red


http://www.opensolaris.org/os/project/nwam

Descripción general de zonaUna zona se puede considerar un contenedor en el que una omás aplicaciones se ejecutan de forma aislada de todas lasdemás aplicaciones del sistema. La mayoría del software que seejecuta en OpenSolaris se ejecuta sin modificaciones en unazona. Dado que las zonas no cambian la interfaz deprogramación de aplicación (API) ni la interfaz binaria deaplicación (ABI) de OpenSolaris, no es necesario compilar denuevo una aplicación para volver a ejecutarla dentro de unazona.

Descripción general de zona


34

Administración de zonasLa administración de zonas se compone de los comandossiguientes:

■ zonecfg: crea y configura zonas (agrega recursos ypropiedades). Almacena la configuración en un archivoXML privado en /etc/zones.

■ zoneadm: lleva a cabo las tareas administrativas de las zonas,como la lista, la instalación, el arranque o la detención.

■ zlogin: permite al usuario iniciar sesión en la zona pararealizar tareas de mantenimiento.

■ zonename: muestra el nombre de zona actual.

Las siguientes propiedades de ámbito global se utilizan con laszonas:

■ zonepath: ruta de la zona global al directorio root en el quese instalará la zona.

■ autoboot: permite decidir si se inicia cuando se arranca lazona global.

■ pool: agrupaciones de recursos a las que deben estarvinculadas las zonas.Los recursos pueden ser de los siguientes tipos:■ fs: sistema de archivos.■ Inherit-pkg-dir: directorio que hereda sus paquetes

asociados de la zona global.■ net: dispositivo de red.■ device: dispositivos.

Administración de zonas


Introducción a la administración de zonasEste ejercicio práctico es una introducción a la creación dezonas.

ResumenSe utilizan ejemplos detallados para enseñar el proceso decreación, instalación y arranque de una zona.

Nota – Este procedimiento no se aplica a una zona de marca lx.

Introducción a la administración de zonas


36

Para crear, instalar y arrancar unazona

Utilice el ejemplo siguiente para configurar una zona nueva:

Nota – El ejemplo siguiente utiliza una pila IP compartida, quees la predeterminada para una zona.

# zonecfg -z Apache

Apache: No such zone configured

Use ’create’ to begin configuring a new zone.

zonecfg:Apache> create

zonecfg:Apache> set zonepath=/export/home/Apache

zonecfg:Apache> add net

zonecfg:Apache:net> set address=192.168.0.50

zonecfg:Apache:net> set physical=bge0

zonecfg:Apache:net> end

zonecfg:Apache> verify

zonecfg:Apache> commit

zonecfg:Apache> exit

Utilice el ejemplo siguiente para instalar y arrancar una zonanueva:

# zoneadm -z Apache install

Preparing to install zone <Apache>.

Creating list of files to copy from the global zone.

Copying <6029> files to the zone.

Initializing zone product registry.

Determining zone package initialization order.

Preparing to initialize <1038> packages on the zone.

Initialized <1038> packages on zone.

Zone <Apache> is initialized.

Installation of these packages generated warnings: ....

The file </export/home/Apache/root/var/sadm/system/logs/install_log>

contains a log of the zone installation.

1

2



Se crean los directorios necesarios. Ya puede arrancar la zona.

Visualice los directorios:# ls /export/home/Apache/root

bin etc home mnt platform sbin

tmp var dev export lib opt

proc system usr

Los paquetes no se reinstalan.

# /etc/mount

/export/home/Apache/root/lib on /lib read only

/export/home/Apache/root/platform on /platform read only

/export/home/Apache/root/sbin on /sbin read only

/export/home/Apache/root/usr on /usr read only

/export/home/Apache/root/proc on proc

read/write/setuid/nodevices/zone=Apache

Arranque la zona.# ifconfig -a

lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>

mtu 8232 index 1 inet 127.0.0.1 netmask ff000000

bge0: flags=1004803<UP,BROADCAST,MULTICAST,DHCP,IPv4> mtu 1500 index 2

inet 192.168.0.4 netmask ffffff00 broadcast 192.168.0.255

ether 0:c0:9f:61:88:c9

# zoneadm -z Apache boot

# ifconfig -a

lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>

mtu 8232 index 1 inet 127.0.0.1 netmask ff000000

lo0:1: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>

mtu 8232 index 1 zone Apache inet 127.0.0.1

bge0: flags=1004803 inet 192.168.0.4 netmask ffffff00 broadcast

192.168.0.255 ether 0:c0:9f:61:88:c9

bge0:1: flags=1000803mtu 1500 index 2 zone Apache inet

192.168.0.50 netmask ffffff00 broadcast 192.168.0.255

Configure la zona e inicie sesión:# zlogin -C Apache

[Connected to zone ’Apache’ pts/5]

3

4

5



38

# ifconfig -a

lo0:2: flags=2001000849 mtu 8232 index 1 inet 127.0.0.1

netmask ff000000

bge0:2: flags=1000803 inet 192.168.0.50 netmask ffffff00

broadcast 192.168.0.255

# ping -s 192.168.0.50

64 bytes from 192.168.0.50: icmp_seq=0. time=0.146 ms

# exit

[Connection to zone ’Apache’ pts/5 closed]



Virtualización del servidor Web con zonasCada zona tiene sus propias características, por ejemplo unnombre, direcciones IP, nombre de host, servicios de nombres,usuarios root y usuarios no root. De modo predeterminado, elsistema operativo se ejecuta en una zona global. Eladministrador puede virtualizar el entorno de ejecucióndefiniendo una o más zonas no globales. Los servicios de red sepueden ejecutar limitando los posibles daños en caso deinfracción de la seguridad. Dado que las zonas se implementanen el software, no están limitadas a la granularidad queestablecen los límites del hardware. Las zonas ofrecengranularidad de la subCPU.

Virtualización del servidor Web con zonas


40

Creación de zonas no globalesEste ejercicio práctico muestra cómo un host físico admite dosconjuntos diferentes de grupos de usuarios de servidor Web.

ResumenEl acceso simultáneo a ambos servidores Web se configura demodo que cada sistema y servidor Web quede protegido en casode que uno de ellos peligre.

Creación de zonas no globales


Creación de dos zonas no globales

Cree una zona no global Apache1:# zonecfg -z Apache1 info

zonepath: /export/home/Apache1

autoboot: false

pool:

inherit-pkg-dir: dir: /lib

inherit-pkg-dir: dir: /platform

inherit-pkg-dir: dir: /sbin

inherit-pkg-dir: dir: /usr

net: address: 192.168.0.100/24

physical: bge0

Cree una zona no global Apache2:# zonecfg -z Apache2 info

zonepath: /export/home/Apache2

autoboot: false

pool:

inherit-pkg-dir: dir: /lib

inherit-pkg-dir: dir: /platform

inherit-pkg-dir: dir: /sbin

inherit-pkg-dir: dir: /usr

net: address: 192.168.0.200/24

physical: bge0

Inicie sesión en Apache1 e instale la aplicación:# zlogin Apache1

# zonename

Apache1

# ls /Apachedir

apache_1.3.9 apache_1.3.9-i86pc-sun-solaris2.270.tar

#cd /Apachedir/apache_1.3.9 ; ./install-bindist.sh /local

You now have successfully installed the Apache 1.3.9 HTTP server.

1

2

3



42

Inicie sesión en Apache2 e instale la aplicación:# zlogin Apache2

# zonename

Apache2

# ls /Apachedir

httpd-2.0.50 httpd-2.0.50-i386-pc-solaris2.8.tar

# cd /Apachedir/httpd-2.0.50; ./install-bindist.sh /local

You now have successfully installed the Apache 2.0.50 HTTP server.

Inicie la aplicación Apache1:# zonename

Apache1

# hostname

Apache1zone

# /local/bin/apachectl start

/local/bin/apachectl start: httpd started

Inicie la aplicación Apache2:# zonename

Apache2

# hostname

Apache2zone

# /local/bin/apachectl start

/local/bin/apachectl start: httpd started

En la zona global, edite el archivo /etc/hosts:# cat /etc/hosts

#

# Internet host table

#

127.0.0.1 localhost

192.168.0.1 loghost

192.168.0.100 Apache1zone

192.168.0.200 Apache2zone

Abra un navegador Web y vaya a la dirección URL siguiente:http://apache1zone/manual/index.html

4

5

6

7

8



El servidor Web Apache1 está en funcionamiento.

Abra un navegador Web y vaya a la dirección URL siguiente:

http://apache2zone/manual/

El servidor Web Apache2 está en funcionamiento.

9

10



44

DiscusiónEl usuario final ve cada zona como un sistema diferente. Cadaservidor Web tiene su propio servicio de nombres:

■ /etc/nsswitch.conf

■ /etc/resolv.conf

Si se produce un ataque en un servidor Web, queda limitado asu zona. Los conflictos de puertos ya no constituyen unproblema.



Creación de agrupaciones dealmacenamiento ZFS y sistemas dearchivos

Cada agrupación de almacenamiento ZFS se compone de uno omás dispositivos virtuales, que describen la disposición delalmacenamiento físico y sus características de errores.

En este módulo, en primer lugar trataremos la configuración deagrupaciones de almacenamiento duplicadas. A continuación,se indica cómo crear una configuración RAID-Z.

Creación de agrupaciones de almacenamiento ZFS y sistemas de archivos


46

Creación de agrupaciones dealmacenamiento ZFS duplicadas

El objetivo de este ejercicio práctico es crear y enumerar laagrupación de almacenamiento duplicada mediante elcomando zpool.

Para obtener información sobre cómo determinar si su entornorequiere la configuración de una agrupación dealmacenamiento ZFS duplicada o RAID-Z, vaya a:http://www.solarisinternals.com/

wiki/index.php/ZFS_Best_Practices_Guide

ResumenZFS es realmente sencillo de utilizar. A continuación, va a crearsu primera agrupación.

Creación de agrupaciones de almacenamiento ZFS duplicadas


http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide


Para crear agrupaciones dealmacenamiento duplicadas

Abra una ventana de terminal.

Cree una agrupación de almacenamiento duplicadadenominada tank. A continuación, visualice la informaciónsobre la agrupación.# zpool create tank mirror c1t1d0 c2t2d0

# zpool status tank

pool: tank

state: ONLINE

scrub: none requested

config:

NAME STATE READ WRITE CKSUM

tank ONLINE 0 0 0

mirror ONLINE 0 0 0

c1t1d0 ONLINE 0 0 0

c2t2d0 ONLINE 0 0 0

errors: No known data errors

La capacidad de los discos c1t1d0 y c2t2d0 es de 36 Gbytescada uno. Dado que los discos están duplicados, la capacidadtotal de la agrupación refleja el tamaño aproximado de uno delos discos. Los metadatos de la agrupación consumen unapequeña cantidad del espacio del disco. Por ejemplo:

# zpool list

NAME SIZE USED AVAIL CAP HEALTH ALTROOT

tank 33.8G 89K 33.7G 0% ONLINE -

1

2

Creación de agrupaciones de almacenamiento ZFS duplicadas


48

Creación de sistemas de archivos ZFScomo directorios de inicio

El objetivo de este ejercicio práctico es aprender a configurar unsistema de archivos ZFS como varios directorios de inicio.

Al utilizar las funciones del sistema de archivos ZFS,disponibles en el proyecto OpenSolaris, puede simplificar elentorno de desarrollo del núcleo implementado instantáneas ysus funciones de inversión.

ResumenUtilizaremos el comando zfs para crear un sistema de archivosy definir su punto de montaje.

Creación de sistemas de archivos ZFS como directorios de inicio


Para crear sistemas de archivos ZFScomo directorios de inicioVisualice el sistema de archivos ZFS predeterminado creadoautomáticamente al crear la agrupación de almacenamiento.# zfs list

NAME USED AVAIL REFER MOUNTPOINT

tank 86K 33.2G 24.5K /tank

Cree el sistema de archivos tank/home:# zfs create tank/home

A continuación, defina el punto de montaje para el sistema dearchivos tank/home:# zfs set mountpoint=/export/home tank/home

Por último, cree los sistemas de archivos tank/homepara todoslos desarrolladores:# zfs create tank/home/developer1

# zfs create tank/home/developer2



La propiedad mountpoint se hereda como prefijo de nombre deruta. Es decir, tank/home/developer1 se montaautomáticamente en /export/home/developer1 porquetank/home está montado en /export/home.

Confirme que se hayan creado los sistemas de archivos ZFS:# zfs list



tank/home 128K 33.2G 29.5K /export/home

tank/home/developer1 24.5K 33.2G 24.5K /export/home/developer1



1

2

3

4

5



50


Realice una instantánea recursiva del sistema de archivostank/home. A continuación, visualice la información deinstantánea:

# zfs snapshot -r tank/home@today

# zfs list



tank/home 128K 33.2G 29.5K /tank/home

tank/home@today 0 - 29.5K -

tank/home/developer1 24.5K 33.2G 24.5K /tank/home/developer1

tank/home/developer1@today 0 - 24.5K -







Para más información, consulte zfs.1m.

6



Creación de una configuración RAID-ZEl objetivo de este ejercicio práctico es mostrarle cómoconfigurar RAID-Z.

ResumenSi desea crear una configuración RAID-Z como alternativa auna configuración de agrupación de almacenamiento duplicadasi necesita maximizar el espacio en disco.

Creación de una configuración RAID-Z


52

Para crear una configuración deRAID-Z


Cree una agrupación con un único dispositivo RAID-Zcompuesto por 5 discos. A continuación, visualice lainformación sobre la agrupación de almacenamiento.

# zpool create tank raidz c1t1d0 c2t2d0 c3t3d0 c4t4d0 c5t5d0

# zpool status tank

pool: tank

state: ONLINE

scrub: none requested

config:

NAME STATE READ WRITE CKSUM

tank ONLINE 0 0 0

raidz1 ONLINE 0 0 0

c1t1d0 ONLINE 0 0 0

c2t2d0 ONLINE 0 0 0

c3t3d0 ONLINE 0 0 0

c4t4d0 ONLINE 0 0 0

c5t5d0 ONLINE 0 0 0

errors: No known data errors

Los discos pueden especificarse utilizando su nombreabreviado o la ruta completa. Por ejemplo, /dev/dsk/c4t4d0 esidéntico a c4t4d0.

Es posible utilizar segmentos de disco para configuraciones deagrupaciones duplicadas y de almacenamiento RAID-Z, perono se recomiendan para entornos de producción. Para obtenermás información sobre el uso de ZFS en entornos deproducción, vaya a: http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide.

1

2

Creación de una configuración RAID-Z




54

Consolidaciones de userland

ObjetivosEl objetivo de este módulo es introducirle a las consolidacionesuserland de OpenSolaris. En general, puede considerar lasconsolidaciones userland como externas al núcleo y comocomponentes con los que interactúan los usuarios. Cada una de lasconsolidaciones siguientes transfieren archivos de origen al sitioWeb opensolaris.org o al centro de descargas. Para acceder acada consolidación, consulte la siguiente dirección URL:http://opensolaris.org/os/downloads/

4M Ó D U L O 4

55

http://opensolaris.org/os/downloads/

Consolidaciones userland y descripciones

Servidor de aplicaciones Servidor de aplicaciones Glassfish

Herramientas deproductos de desarrollo(DevPro)

La biblioteca matemática del sistema, labiblioteca de medios, la biblioteca demicrotareas, SCCS y make y las bibliotecas detiempo de ejecución C++.

Documentación (Docs) Documentación técnica de desarrollo yadministración.

Globalización (G11N) Internacionalización y localización.

Instalación (Install) Admisión de instalación y herramientas deempaquetado.

Java Desktop (JDS) Solución de software de escritorio empresarialsegura y completa.

Plataforma Java,Standard Edition (JavaSE)

Hay disponibles binarios para JavaDevelopment Kit (JDK) y Java RuntimeEnvironment (JRE).

Páginas del comandoman

Código fuente para las páginas del manual dereferencia de SunOS.

Message Queue Sun Java System Message Queue.

Almacenamiento de red(NWS)

Compatibilidad con dispositivos dealmacenamiento de red.

SFW (Solaris FreeWare) Software de código abierto integrado conSolaris/OpenSolaris.

Compatibilidad congráficos SPARC

La consolidación de gráficos SPARC tienedisponibles controladores en formato binario.

Pruebas Herramientas de prueba y conjuntos depruebas OpenSolaris.



56

Sistema de ventanas X(X11)

Software X11.


Módulo 4 • Consolidaciones de userland 57

58

Características principales delsistema operativo Solaris

ObjetivosLa finalidad de este módulo es describir las característicasprincipales del sistema operativo Solaris y cómo han cambiado deforma sustancial el funcionamiento del sistema operativo.

Recursos adicionalesOpenSolaris Development Process;http://www.opensolaris.org/

os/community/onnv/os_dev_process/

C Style and Coding Standards for SunOS;http://www.opensolaris.org/

os/community/documentation/getting_started_docs/

5M Ó D U L O 5

59

http://www.opensolaris.org/os/community/onnv/os_dev_process/


http://www.opensolaris.org/os/community/documentation/getting_started_docs/


Proceso de desarrollo y estilo de códigoLos pasos del proceso de desarrollo y el estilo de código que seutilizan en la consolidación OS/Net (ON) se utilizan paraofrecer los principales componentes del sistema operativo y dered a Solaris. ON contiene el código del núcleo y todas lasplataformas (en todas las arquitecturas), la mayoría de loscontroladores, los sistemas de archivos, las bibliotecasprincipales y los comandos básicos de un sistema Solaris.Elproceso de desarrollo del proyecto OpenSolaris sigue esteprocedimiento de alto nivel:

1. IdeaEn primer lugar, alguien tiene una idea para realizar unamejora o una queja sobre un defecto. Busque un error,registre uno nuevo o solicite una mejora enhttp://bugs.opensolaris.org/. A continuación, anunciesu solicitud a los demás desarrolladores en la lista de correopertinente. La posibilidad de anunciar la solicitud aportauna serie de ventajas:■ Acelera el proceso de debate sobre el cambio o la mejora■ Determina la complejidad de los cambios propuestos■ Evalúa el interés de la comunidad■ Identifica los posibles miembros del equipo

2. DiseñoEn la fase de diseño se decide si es necesario revisar undiseño formal. Si lo es, siga estos pasos:■ Identifique los revisores del diseño y la arquitectura■ Escriba un documento de diseño■ Escriba un plan de prueba■ Lleve a cabo revisiones de diseño y obtenga la

aprobación correspondiente3. Implementación

La fase de implementación se compone de lo siguiente:

Proceso de desarrollo y estilo de código


60

http://bugs.opensolaris.org/

■ Escritura del código de acuerdo con las políticas ynormas

Descargue C Style and Coding Standards for SunOSaquí:http://www.opensolaris.org/os/community/documentation/getting_started_docs/.

■ Escritura de los conjuntos de pruebas■ Aprobación de las diferentes pruebas de unidad y

preintegración■ Escritura o actualización de la documentación del

usuario, si se requiere■ Identificación de los revisores del código para preparar

la integración

4. Integración

La integración tiene lugar una vez se han completado todaslas revisiones y concedido los permisos.

En la fase de integración se comprueba si se han llevado a cabotodas las acciones previstas, para lo que se revisa el código, ladocumentación y la finalización.

El documento del proceso formal de OpenSolaris describe lospasos anteriores de forma más detallada, con diagramas de flujoque ilustran las fases de desarrollo. También especifica lossiguientes valores básicos y principios de diseño que se aplicanal desarrollo de código fuente para el proyecto OpenSolaris:

■ Fiabilidad: OpenSolaris debe funcionar correctamente yofrecer resultados precisos sin perder ni dañar datos.

■ Disponibilidad: los servicios deben configurarse comoreiniciables en caso de error de la aplicación, y OpenSolarisdebe poder recuperarse de errores de hardware que no seangraves.


Módulo 5 • Características principales del sistema operativo Solaris 61



■ Facilidad de mantenimiento: debe poderse diagnosticartanto los errores graves como los transitorios y, cuando seaposible, automatizar el diagnóstico.

■ Seguridad: la seguridad de OpenSolaris debe integrarse enel sistema operativo y contar con mecanismos para auditarlos cambios que se realizan en el sistema y la persona que loslleva a cabo.

■ Rendimiento: el rendimiento de OpenSolaris debe serinsuperable en comparación con otros sistemas operativosque se ejecutan en entornos idénticos.

■ Facilidad de uso: debe permitir la administración decomponentes individuales, software o hardware de maneracoherente y directa.

■ Compatibilidad: los nuevos subsistemas e interfaces debenpoder ampliarse y admitir nuevas versiones para incorporarfuturos cambios y mejoras sin que peligre la compatibilidad.

■ Facilidad de mantenimiento: OpenSolaris debe generarsede modo que las subrutinas comunes se combinen enmódulos de núcleos o bibliotecas que los pueda utilizar unnúmero aleatorio de usuarios.

■ Neutralidad de plataforma: OpenSolaris debe seguirteniendo una plataforma neutra; asimismo, deben diseñarseabstracciones de nivel reducidas teniendo en cuentadiferentes y futuras plataformas.

Consulte http://www.opensolaris.org/os/community/onnv/os_dev_process/ para obtenerinformación más detallada acerca del proceso que se sigue parael desarrollo colaborativo de código de OpenSolaris.

Al igual que otros muchos proyectos, OpenSolaris aplica unestilo de código al código que se aporta, sea cual sea su origen.Este estilo se describe detalladamente enhttp://opensolaris.org/os/community/onnv/.



62



http://opensolaris.org/os/community/onnv/

La distribución de OpenSolaris incluye dos herramientas paracomprobar numerosos elementos del estilo de código. Estasherramientas son; cstyle(1), para verificar el cumplimientodel código C con la mayoría de las normas de estilo, yhdrchk(1), para comprobar el estilo de las cabeceras de C yC++.



Información generalUna vez considerados el entorno de desarrollo, los procesos yvalores que aplican los desarrolladores en el proceso deingeniería, describiremos más detalladamente las funciones delsistema operativo que ejemplifican el rendimiento, laseguridad, la capacidad de servicio y la manejabilidad:

■ Rendimiento■ FireEngine■ Nemo■ Crossbow

■ Seguridad■ Minimización de los privilegios■ Filtros de paquetes■ Zonas■ Zonas de marca (BrandZ)

■ Facilidad de mantenimiento■ Recuperación automática predecible■ Tecnología Dynamic Tracing (DTrace)■ Modular Debugger (MDB)

■ Capacidad de control■ Utilidad de gestión de servicios (SMF)■ ZFS

FireEngineEl enfoque de FireEngine en Solaris 10 combina todas las capasde protocolo en un módulo STREAMS de subproceso múltiple.En el módulo combinado, en lugar de bloqueos de estructurapor datos, se utiliza un mecanismo de sincronización por CPUdenominado "perímetro vertical". El "perímetro vertical" seimplementa utilizando una abstracción de cola de serialización

Información general


64

denominada "squeue". Cada squeue está vinculada a una CPU,y cada conexión está a su vez vinculada a una squeue queproporciona la sincronización y exclusión mutua necesariapara las estructuras de datos específicas de la conexión.

SincronizaciónDado que la pila cuenta con múltiples subprocesos (y bloquea laserialización por CPU que aplica el perímetro vertical), utilizaun esquema basado en referencias para asegurar que haya unainstancia de conexión cuando se necesite. Para una conexiónTCP establecida, se garantiza la existencia de tres referencias.Cada capa de protocolo cuenta con una referencia en lainstancia (una para TCP e IP) y el clasificador tiene unareferencia al tratarse de una conexión establecida. Cada vez quellega un paquete para la conexión y el clasificador consulta lainstancia de conexión, se coloca una referencia adicional, que sesuelta cuando la capa de protocolo termina de procesar elpaquete.

TCP, IP y UDPEl sistema operativo Solaris 10 proporciona la misma vista paraTCP que las versiones anteriores, es decir, TCP aparece comodispositivo de copia pero en realidad es un compuesto, con elcódigo TCP e IP combinado en un único módulo D_MPSTREAMS. La parte operativa de TCP está completamenteprotegida por el perímetro vertical que se activa mediante lasprimitivas de squeue. FireEngine cambia la interfaz entre TCP eIP desde la interfaz de transferencia de mensajes basada enSTREAMS hasta una interfaz funcional basada en llamadas,ambas en las rutas de control y datos.

Hay un módulo UDP completo con múltiples subprocesos enejecución en el mismo dominio de protección que IP. AunqueUDP e IP se ejecutan en el mismo dominio de protección,siguen siendo módulos STREAMS separados. Por tanto, el



establecimiento de STREAMS se mantiene sin cambios ysiempre se coloca una instancia del módulo UDP por encima deIP. La plataforma de Solaris 10 permite los siguientes modos deestablecimiento:■ Normal: IP se abre primero y luego se coloca encima UDP.

Es la acción predeterminada que tiene lugar cuando se abreun dispositivo o socket UDP.

■ SNMP: UDP se coloca encima de un módulo que no sea IP.Cuando esto ocurre, sólo se admite semántica SNMP.

GLDv3El software Solaris 10 introduce una nueva estructura decontroladores de dispositivos denominada GLDv3 junto con lanueva pila. La mayoría de los controladores de dispositivos seha pasado a esta estructura, y todos los controladores dedispositivos de 10 Gb y futuros se basarán en ella. Estaestructura también proporciona una capa DLPI basada enSTREAMS para la compatibilidad con versiones anteriores(para permitir que los módulos externos que no sean IP siganfuncionando). La arquitectura GLDv3 virtualiza la capa dos dela pila de red. Ya no existe una correspondencia uno a uno entrelas interfaces de red y los dispositivos.

Consulte el proyecto Nemo en opensolaris.org para obtenermás información sobre la estructura, el módulo de serviciosMAC y el módulo de servicios de vínculo de datos.

VirtualizaciónEl proyecto Crossbow crea pilas virtuales para cualquierservicio (HTTP, HTTPS, FTP, NFS, etc.), protocolo (TCP, UDP,SCTP, etc.) o tecnología de Solaris Containers. Las pilasvirtuales se separan mediante un motor de clasificación H/Wpara que el tráfico de una pila no repercuta en otras pilasvirtuales. A cada pila virtual se puede asignar su propia



66

prioridad y su propio ancho de banda en una NIC compartidasin que ello perjudique al rendimiento del sistema o alservicio/contenedor. La arquitectura administradinámicamente los recursos de prioridad y ancho de banda, ypuede proporcionar una mejor protección contra ataques dedenegación de servicios dirigidos a un servicio o contenedorespecífico aislando el impacto sólo a dicho servicio ocontenedor.

Minimización de los privilegiosHistóricamente, UNIX® ha tenido siempre un modelo deprivilegios de "todo o nada" que impone las restriccionessiguientes:

■ No existe modo alguno de limitar los privilegios de usuariosroot

■ Los usuarios que no sean root no pueden realizaroperaciones con privilegios

■ Las aplicaciones que sólo necesitan algunas operaciones conprivilegios deben ejecutarse como root

■ Los privilegios de root se confían a muy pocos, y entre ellosno hay casi ningún estudiante

En el sistema operativo Solaris, hemos desarrollado privilegiosavanzados. Permiten la ejecución de aplicaciones y el uso oacceso a funciones justo con los privilegios que se necesitan. Elprivilegio mínimo permite a los estudiantes completar sutrabajo, participar en investigaciones y mantener una parte dela infraestructura del departamento o el campus.



Filtros de paquetesEl filtro IP de Solaris proporciona un filtrado de paquetes conestado y traducción de direcciones de red (NAT). El filtro IP deSolaris se deriva de software de filtro IP de código abierto. Elfiltro IP puede filtrar por dirección IP, puerto, protocolo ointerfaz de red de acuerdo con las reglas de filtros.

Filtro IPLa API de enlaces de filtros de paquetes (PFHooks) se haintroducido desde Solaris 10 Update 4, para reemplazar laimplementación basada en STREAMS del filtro IP. Con el usode la estructura PFHooks, el rendimiento del softwarecortafuegos como el filtro IP se ha mejoradoconsiderablemente. PFhooks también permite interceptar eltráfico en bucle y entre zonas. El software cortafuegos de otrosproveedores se desarrolla y registra con la API PFHooksutilizando el enlace net_register_hook(info, event,hook);.

Activación de filtros de paquetes sencillosEl objetivo de este ejercicio es aprender sobre los filtros depaquetes. El filtro IP de Solaris se instala con el sistemaoperativo Solaris. Sin embargo, los filtros de paquetes no estánactivos de modo predeterminado. El filtro IP puede filtrar pordirección IP, puerto, protocolo o interfaz de red de acuerdo conlas reglas de filtros. A continuación se incluye un ejemplo deregla de filtro:

block in on ce0 proto tcp from 192.168.0.0/16 to any port = 23

Para utilizar el filtro IP de Solaris, especifique las reglas de filtrosen el archivo /etc/ipf/ipf.conf. A continuación, active yreinicie el servicio svc:network/ipfilter utilizando elcomando svcadm.



68

Nota – También puede utilizar el comando ipf con losconjuntos de reglas.

El filtro IP de Solaris puede llevar a cabo la traducción dedirecciones de red (NAT) para una dirección de origen odestino de acuerdo con las reglas NAT. A continuación seincluye un ejemplo de regla NAT:

map ce0 192.168.1.0/24 -> 10.1.0.0/16

Para utilizar la traducción de direcciones de red, especifique lasreglas NAT en el archivo /etc/ipf/ipnat.conf. Acontinuación, active y reinicie el serviciosvc:/network/ipfilter utilizando el comando svcadm.

Nota – También puede utilizar el comando ipnat para trabajarcon conjuntos de reglas.

Reglas de filtros de paquetes de ejemploEn esta sección se incluyen varios ejemplos de sintaxis de reglasde filtros. Invoque las reglas agregándolas al archivo/etc/ipf/ipf.conf. A continuación, active el filtro IP deSolaris y rearranque el equipo tal como se detalla en el ejercicioanterior.

Registre en le0 todos los paquetes entrantes que cuenten conopciones de IP.

log in on le0 from any to any with ipopts

Bloquee en le0 los paquetes entrantes que estén fragmentados ysean demasiado pequeños para poder llevar a cabo unacomparación significativa. Esta acción sólo se aplica a lospaquetes TCP que puedan carecer de indicadores/puertos (enfunción de la parte del fragmento que vea).



block in log quick on le0 from any to any with short frag

Registre todos los paquetes TCP entrantes con el conjunto deindicadores SYN (solamente).

Nota – Si se trata de un paquete TCP entrante con el conjunto deindicadores SYN y cuenta con opciones de IP, esta regla y laanterior lo registrarían por duplicado.

log in on le0 proto tcp from any to any flags S/SA

Bloquee y registre las instrucciones ICMP entrantesinaccesibles.

block in log on le0 proto icmp from any to any icmp-type unreach

Bloquee y registre en le0 los paquetes UDP entrantes que sedirijan al puerto 2049 (el puerto NFS).

block in log on le0 proto udp from any to any port = 2049

Admita rápidamente la transferencia de paquetes de un par dehosts concreto.

pass in quick from any to 10.1.3.2/32

pass in quick from any to 10.1.0.13/32

pass in quick from 10.1.3.2/32 to any

pass in quick from 10.1.0.13/32 to any

Bloquee y detenga la coincidencia de cualquier paquete conopciones de IP.

block in quick on le0 from any to any with ipopts

Permite la transferencia de cualquier paquete.

pass in from any to any



70

Bloquee los paquetes UDP entrantes destinados a estassubredes.

block in on le0 proto udp from any to 10.1.3.0/24



Bloquee cualquier paquete TCP entrante que sólo tengan elconjunto de indicadores SYN y estén destinados a estassubredes.

block in on le0 proto tcp from any to 10.1.3.0/24 flags S/SA



Bloquee cualquier paquete ICMP entrante destinado a estassubredes.

block in on le0 proto icmp from any to 10.1.3.0/24



ZonasUna zona es una abstracción virtual del sistema operativo queofrece un entorno protegido en el que se ejecutan lasaplicaciones. Las aplicaciones se protegen unas de otras paraaislar los errores de software. Para facilitar la administración demúltiples aplicaciones y sus entornos, coexisten en unainstancia del sistema operativo y normalmente se gestionancomo una entidad.

Ciertas aplicaciones que normalmente se ejecutan como root ocon algunos privilegios quizá no se ejecuten dentro de una zonasi dicha ejecución depende de su capacidad para acceder ocambiar algún recurso global. Un ejemplo sería la posibilidadde cambiar el reloj del sistema. Las pocas aplicaciones que se



ajustan a estos criterios pueden necesitar que las aplicaciones seejecuten correctamente dentro de una zona o, en ocasiones,deben seguir utilizándose dentro de la zona global.

A continuación se establecen algunas pautas:

■ Una aplicación que accede a la red y los archivos y no lleva acabo ninguna tarea adicional de E/S debería funcionar sinproblemas.

■ Las aplicaciones que requieren acceso directo adeterminados dispositivos, por ejemplo, una partición dedisco, suelen funcionar si la zona se ha configuradocorrectamente. Sin embargo, en ocasiones esto puedeafectar a la seguridad.

■ Es posible que se deban modificar las aplicaciones querequieren acceso directo a estos dispositivos para quefuncionen correctamente. Por ejemplo, /dev/kmem o undispositivo de red. Las aplicaciones deben utilizar uno de losmúltiples servicios IP.

Las zonas se pueden combinar con las utilidades deadministración de recursos que incluye OpenSolaris paraofrecer entornos aislados más completos. Mientras que la zonaproporciona la seguridad, el espacio de nombre y el aislamientode errores, se pueden utilizar las utilidades de administraciónde recursos para impedir que los procesos de una zona utilicendemasiados recursos de un sistema o para garantizarles ciertonivel de servicio. De forma conjunta, las zonas y laadministración de recursos se suelen denominar"contenedores".

Consultehttp://opensolaris.org/os/community/zones/faq para verla respuesta a una gran cantidad de preguntas frecuentes sobrelas zonas y vínculos a la documentación más reciente sobreadministración.



72

http://opensolaris.org/os/community/zones/faq

Las zonas proporcionan entornos protegidos para lasaplicaciones de Solaris.Mediante el uso de BrandZ en elproyecto OpenSolaris hay disponibles entornos de ejecuciónindependientes y protegidos.

Zonas de marca (BrandZ)BrandZ es un sistema que amplía la infraestructura de las zonaspara crear zonas de marca, que son zonas que contienenentornos operativos no nativos. Una zona de marca puederesultar tan sencilla como un entorno en que las utilidadesestándar de Solaris se sustituyen por sus equivalentes GNU, otan compleja como un espacio de usuario completo de Linux.

BrandZ amplía la infraestructura de zonas en el espacio delusuario de los modos siguientes:

■ Una marca es un atributo de una zona, que se define durantela configuración de la misma.

■ Cada marca tiene su propia rutina de instalación, quepermite instalar un determinado grupo de software en lazona de marca.

■ Cada marca puede proporcionar secuencias previas yposteriores al inicio que permitan al usuario configurardurante el arranque.

■ Las herramientas zonecfg y zoneadm pueden definir einformar del tipo de marca de una zona.

BrandZ proporciona un conjunto de puntos de interposiciónen el núcleo:

■ Estos puntos se encuentran en la ruta syscall, la ruta decarga del proceso, la ruta de creación de divisiones, etc.

■ Estos puntos de interposición sólo se aplican a los procesosde una zona de marca.



■ En cada uno de estos puntos, una marca puede decidir si elcomportamiento estándar del sistema operativo Solaris secomplementa o se sustituye.

■ Las marcas fundamentalmente distintas pueden requerirnuevos puntos de interposición.

La marca lx permite que las aplicaciones binarias de Linux seejecuten sin modificaciones en Solaris, dentro de zonas queejecutan un espacio de usuario completo de Linux. La marca lxpermite que el software de usuario de Linux se ejecute en unamáquina con un núcleo de OpenSolaris, e incluye lasherramientas necesarias para instalar una distribución CentOSo Red Hat Enterprise Linux dentro de una zona en un sistemaSolaris. La marca lx se ejecuta en sistemas x86/x64 iniciadoscon un núcleo de 32 o 64 bits. Sea cual sea el núcleo subyacente,sólo se pueden ejecutar aplicaciones Linux de 32 bits. Estafunción sólo está disponible actualmente para arquitecturas x86y AMD x64. Sin embargo, pasar a SPARC podría ser unproyecto interesante para la comunidad ya que BrandZ lx estodavía algo que se está desarrollando.

Consultehttp://opensolaris.org/os/community/brandz/install

para ver las instrucciones y los requisitos de instalación.

El proyecto OpenSolaris afronta los desafíos exclusivos deldesarrollo de sistemas operativos y las pruebas para elrendimiento de las aplicaciones utilizando funciones como laszonas.

Redes de zonasLas zonas de Solaris se pueden designar como:

■ Zona de IP exclusiva■ Zona de IP compartida



74

http://opensolaris.org/os/community/brandz/install

Las zonas de IP exclusiva tienen sus propias pilas de IP ypueden tener sus propias interfaces físicas. Una zona de IPexclusiva también puede tener sus propias interfaces VLAN. Laconfiguración de zonas de IP exclusiva es la misma que la de unequipo físico.

Las zonas de IP compartida comparten la pila de IP con la zonaglobal, de modo que las zonas de IP compartida se aíslan de laconfiguración de los dispositivos, el encaminamiento, etc. Acada zona de IP compartida se pueden asignar direccionesIPv4/IPv6. Cada zona de IP compartida también tiene supropio espacio de puerto. Las aplicaciones se pueden vincular aINADDR_ANY y sólo recibir tráfico para esa zona.

Ninguno de los dos tipos de zonas puede ver el tráfico de otraszonas. Los paquetes que provienen de una zona tienen unadirección de origen que pertenece a dicha zona. Una zona de IPcompartida sólo puede enviar paquetes en una interfaz en laque tenga una dirección. Una zona de IP compartida sólo puedeutilizar un encaminador predeterminado si se puede acceder aél directamente desde la zona. El encaminador predeterminadodebe encontrarse en la misma subred IP que la zona.

Las zonas de IP compartida no pueden modificar suconfiguración de red o su tabla de encaminamiento, y nopueden ver la configuración de otras zonas. /dev/ipno estápresente en la zona de IP compartida. En lugar de ello, losagentes SNMP deben abrir /dev/arp. Varias zonas de IPcompartida pueden compartir una dirección de emisión ypueden unirse al mismo grupo multidifusión.

Las zonas de IP compartida tienen las siguientes limitaciones dered:■ No es posible colocar una interfaz física dentro de una zona.■ IPFilter no trabaja entre zonas.■ No hay protocolo DHCP para las direcciones IP de las

zonas.



■ No hay encaminamiento dinámico.

Las zonas de IP exclusiva no tienen las limitaciones anteriores, ypueden cambiar su configuración de red o tabla deencaminamiento dentro de la zona. /dev/ip está presente en lazona de IP exclusiva.

Identidad de zonas, visibilidad de la CPU yempaquetamientoCada zona controla su nombre de nodo, zona horaria yservicios de nombres como LDAP y NIS. sysidtool permiteconfigurarlos. Si hay distintos archivos /etc/passwd, significaque los privilegios de root se pueden delegar a la zona. Los IDde usuario se pueden asignar a diferentes nombres cuando losdominios son distintos.

De modo predeterminado, todas las zonas ven todas las CPU.La vista restringida se activa de forma automática cuando sehabilitan las agrupaciones de recursos.

Las zonas pueden agregar sus propios paquetes. Se puedencrear parches para esos paquetes. Los parches del sistema seaplican en la zona global. Por tanto, en las zonas no globales lazona inicia automáticamente -s para aplicar el parche. Elpaquete SUNW_PKG_ALLZONES debe mantenerse de formacoherente entre la zona global y todas las zonas no globales.SUNW_PKG_HOLLOW hace que el nombre del paqueteaparezca en las zonas no globales (NGZ) por motivos dedependencia, pero no se instala el contenido.

Dispositivos de zonasCada zona tiene sus propios dispositivos. Las zonas ven unsubconjunto de pseudodispositivos seguros en su directorio/dev. Las aplicaciones hacen referencia a la ruta lógica de undispositivo presentado en /dev. El directorio /dev existe en las



76

zonas no globales, pero no el directorio /devices. Losdispositivos como random, console y null son seguros, perootros como /dev/kmem no lo son.

Las zonas pueden modificar los permisos de sus dispositivos,pero no pueden emitir mknod(2). Los archivos de dispositivosfísicos como los de los discos sin procesar se pueden colocar enuna zona tomando determinadas precauciones. Las zonaspueden compartir dispositivos, pero es necesario adoptarciertas medidas de seguridad.

Por ejemplo, quizá tenga dispositivos que desee asignar a zonasespecíficas. Si se permite a los usuarios sin privilegios acceder alos dispositivos de bloques, éstos se podrían utilizar para crearuna situación crítica del sistema, reiniciar el bus u otrasacciones malintencionadas. Si se coloca un dispositivo físico enmás de una zona, puede crearse un canal oculto entre las zonas.Las aplicaciones de zonas globales que utilizan dichosdispositivos pueden provocar que una zona no global dañe losdatos o los ponga en peligro.

Recuperación automáticapredecibleLa tecnología de reparación preventiva Predictive Self-Healingse implantó de dos modos en el sistema operativo Solaris 10. Enesta sección se describen las nuevas tecnologías FaultManagement Architecture y Services Management Facility quecomponen la tecnología de reparación preventiva.

Fault Management Architecture (FMA)El sistema operativo Solaris proporciona una nuevaarquitectura, FMA, para generar controles de errores concapacidad de recuperación, telemetría de errores, software de



diagnóstico automatizado, agentes de respuestas y un modelocoherente de errores del sistema para la pila de tareas deadministración. Muchas partes de Solaris ya participan en laarquitectura FMA, incluida la CPU y el control de errores de lamemoria para UltraSPARC III y IV, los adaptadores de bus PCIUltraSPARC y Opteron. Se están desarrollando una serie deproyectos, incluida la compatibilidad total para la CPU, lamemoria y los errores de E/S en Opteron, la conversión decontroladores de dispositivos clave y la integración con variaspilas de administración.

Cuando se convierte un subsistema para participar en laadministración de errores, el control de errores se puederecuperar para que el sistema pueda seguir funcionando a pesardel error, y se producen eventos de telemetría que generan deforma automatizada un diagnóstico y una respuesta. Laarquitectura y las herramientas de administración de errorespermiten desarrollar contenido de autorrecuperación para loserrores de software y hardware, para recursos del sistema tantomicroscópicos como macroscópicos. Todo con una única vistasimplificada para los administradores y el software deadministración del sistema.

Consulte http://opensolaris.org/os/community/fm paraobtener información sobre cómo participar en la comunidad deadministración de errores o descargar la base de información degestión MIB que se está desarrollando.

Dynamic Tracing (DTrace)DTrace proporciona una potente infraestructura que permite alos administradores, desarrolladores y personal de servicioresponder de forma concisa a las preguntas mas diversas sobreel comportamiento del sistema operativo y los programas delusuario. DTrace permite:

■ Permitir y administrar dinámicamente miles de sondeos



78

http://opensolaris.org/os/community/fm

■ Asociar dinámicamente predicados y acciones con sondeos■ Administrar dinámicamente búfers de trama y gastos de

sondeos■ Examinar los datos de rastreo de un sistema activo o un

volcado del sistema■ Implementar nuevos proveedores de datos de rastreo que se

conecten a DTrace■ Implementar consumidores de datos de rastreo que

proporcionen presentaciones de datos■ Implementar herramientas que configuren los sondeos de

DTrace

Encontrará las páginas de la comunidad de DTrace en ladirección siguiente:http://opensolaris.org/os/community/dtrace.

Además de DTrace, el proyecto OpenSolaris ofrece funcionesde depuración para los tipos de desarrollo de bajo nivel, porejemplo, el desarrollo de controladores de dispositivos.

Modular Debugger (MDB)MDB es un depurador que facilita el análisis de problemas querequieren funciones de depuración de bajo nivel, el examen dearchivos núcleo y el lenguaje ensamblador para diagnosticar ycorregir. Generalmente, los desarrolladores de núcleos ydispositivos se basan en mdb para determinar el motivo y ellugar donde se produce un error de código.

MDB está disponible en forma de dos comandos quecomparten funciones comunes: mdb y kmdb. Puede utilizar elcomando mdb de forma interactiva o en secuencias para depurarprocesos activos del usuario, archivos de núcleo de procesos delusuario, volcados del núcleo, el sistema activo, archivos de



http://opensolaris.org/os/community/dtrace

objetos y otros archivos. Puede utilizar el comando kmdb paradepurar el núcleo del sistema operativo activo y loscontroladores de dispositivos cuando también deba controlar ydetener la ejecución del núcleo.

Existe una comunidad activa para MDB. En ella puede formularpreguntas a expertos, o leer conversaciones anteriores ypreguntas habituales. Consultehttp://opensolaris.org/os/community/mdb.

Sistema de archivos ZFSLos sistemas de archivos ZFS no se limitan a dispositivosconcretos, de modo que se pueden crear de forma fácil y rápidacomo directorios. Aumentan automáticamente en el espacioasignado a la agrupación de almacenamiento.

Suma de comprobación y recuperación dedatosEn ZFS se efectúa una suma de comprobación de todos losdatos y metadatos mediante un algoritmo seleccionable por elusuario. La recuperación de todos los datos y las sumas decomprobación se efectúa en la capa del sistema de archivos, y estransparente para todas las aplicaciones. Asimismo, ZFS ofrecesoluciones para la reparación automática de datos. ZFS admitegrupos de almacenamiento con diversos niveles de redundanciade datos que incluyen la duplicación y una variación sobreRAID-5. Si se detecta un bloque de datos incorrecto, ZFSrecupera los datos correctos de otra copia redundante y reparalos datos anómalos sustituyéndolos por la copia buena.

ZFS presenta un modelo de almacenamiento agrupado queelimina el concepto de volúmenes y los problemas asociados departiciones, configuración, mal uso del ancho de banda yalmacenamiento no válido.



80

http://opensolaris.org/os/community/mdb

El ancho de banda de E/S combinado de todos los dispositivosde la agrupación está disponible para todos los sistemas dearchivos en todo momento.

Cada agrupación de almacenamiento se compone de uno o másdispositivos virtuales, que describen la disposición delalmacenamiento físico y sus características de errores. Consulteen la páginahttp://opensolaris.org/os/community/zfs/demos/basics

la demostración 100 Mirrored Filesystems in 5 Minutes, quepresenta la administración sistemas de archivos ZFS.

RAID-ZAdemás del almacenamiento agrupado, ZFS proporcionaconfiguraciones de redundancia de datos RAID-Z yredundantes con duplicaciones. RAID-Z es un dispositivovirtual que almacena datos y paridad en varios discos, similar aRAID-5.

En RAID-Z, ZFS utiliza divisiones RAID de ancho variable paraque todas las escrituras estén totalmente divididas. Esto sólo esposible gracias a la integración que ZFS hace del sistema dearchivos y la administración de dispositivos, de modo que losmetadatos del sistema de archivos tienen suficienteinformación sobre el modelo de réplica de datos subyacentepara controlar las divisiones RAID de ancho variable. RAID-Zes la principal solución de sólo software existente para el"agujero de escritura" de RAID-5.

Utilidad de gestión de servicios(SMF)SMF crea un modelo unificado y compatible para la gestión deuna gran cantidad de servicios, como la entrega de correoelectrónico, las solicitudes ftp y la ejecución remota de



http://opensolaris.org/os/community/zfs/demos/basics

comandos en el proyecto OpenSolaris. La estructura smf(5)sustituye (de un modo compatible) el mecanismo de inicioinit.d(4) existente y mejora inetd(1M). SMF ofrece a losdesarrolladores lo siguiente:

■ Reinicio automatizado de los servicios por orden dedependencia debidos a errores incorregibles de software,hardware o administrativos

■ Una única API para la administración, configuración yobservación de servicios

■ Acceso a la administración de recursos basada en servicios■ Depuración simplificada del proceso de arranque

Consultehttp://opensolaris.org/os/community/smf/scfdot paraver un gráfico de los servicios SMF y sus dependencias en unsistema x86 en el que se acaba de instalar el sistema operativoSolaris Nevada.



82

http://opensolaris.org/os/community/smf/scfdot

Conceptos de programación

ObjetivosEste módulo ofrece una descripción avanzada de los conceptosfundamentales del entorno de programación de OpenSolaris:

■ Administración del sistema y los procesos■ Programación de subprocesos■ Descripción general del núcleo■ Planificación de la CPU■ Depuración de procesos

Recursos adicionales■ Solaris Internals (2nd Edition), Prentice Hall PTR (12 de mayo

de 2006), de Jim Mauro y Richard McDougall■ Solaris Systems Programming, Prentice Hall PTR (19 de agosto

de 2004), de Rich Teer■ Multithreaded Programming Guide Sun Microsystems, Inc.,

2005.■ STREAMS Programming Guide. Sun Microsystems, Inc., 2005.■ Solaris 64-bit Developer’s Guide Sun Microsystems, Inc., 2005.

6M Ó D U L O 6

83

Administración del sistema y los procesosLa unidad básica de trabajo es el proceso. Los ID de proceso(PID) se enumeran secuencialmente en el sistema. De modopredeterminado, el administrador del sistema asigna a cadausuario un proyecto, que es un identificador administrativo enla red. Cada inicio de sesión que se realiza correctamente en unproyecto crea una tarea, que constituye un mecanismo deagrupación para los procesos. Una tarea contiene el proceso deinicio de sesión, así como los procesos secundariossubsiguientes.

La utilidad de agrupación de recursos une los recursos ligados aprocesos en una abstracción común denominada agrupación.Los grupos de procesos y otras entidades se configuran,agrupan y etiquetan de modo que los componentes de trabajose asocian con un subconjunto de los recursos totales de unsistema. Cuando la utilidad de agrupaciones está desactivada,todos los procesos pertenecen a la misma agrupación,pool_default, y los grupos de procesadores se administran através de la llamada de sistema pset(). Cuando la utilidad deagrupaciones está activada, debe utilizarse para administrar losgrupos de procesadores. Es posible crear agrupaciones yasociarlas con los grupos de procesadores. Los procesos puedenestar vinculados a agrupaciones que tengan conjuntos derecursos que no estén vacíos.

Si en OpenGrok se busca pool.c, se encontrarán numerososcomentarios sobre código que describen las relaciones entre lastareas, las agrupaciones, los proyectos y los procesos del modosiguiente:

La operación que vincula los proyectos y las tareas con lasagrupaciones es atómica. Eso significa que se vincularán todoslos procesos de un determinado proyecto o tarea a una nuevaagrupación o, en caso de error, permanecerán vinculados a laantigua agrupación. Los procesos de un determinado proyecto

Administración del sistema y los procesos


84

o tarea sólo se pueden vincular a diferentes agrupaciones si sevuelven a vincular de forma individual como procesos únicos.Los subprocesos o LWP del mismo proceso no tienen vínculosde agrupaciones, y se vinculan al mismo grupo de recursosasociado con la agrupación de recursos del proceso en cuestión.

Los procesos cuentan con la posibilidad de ejecutarse dentro deuna zona. Las zonas las configuran los administradores delsistema, normalmente por motivos de seguridad, para aislargrupos de usuarios de procesos.

Programación de subprocesosUna vez descritos los procesos en el contexto de las tareas, losproyectos, las agrupaciones de recursos, las zonas y las zonas demarca, pasaremos al contexto de los subprocesos. El sistemaUNIX tradicional ya admite el concepto de subprocesos. Cadaproceso contiene un único subproceso, de modo queprogramar con varios procesos implica programar con variossubprocesos. Sin embargo, un proceso también es un espacio dedirecciones; crear un proceso implica crear un nuevo espacio dedirecciones.

La comunicación entre los subprocesos de un proceso resultasencilla porque lo comparten todo, incluidos los descriptores dearchivos abiertos y un espacio de direcciones común. De estemodo, los datos producidos por un subproceso estáninmediatamente disponibles para todos los demás subprocesos.

Las bibliotecas son libpthread para los subprocesos POSIX ylibthread para los subprocesos de OpenSolaris. El subprocesomúltiple ofrece flexibilidad al desvincular los recursos delnúcleo y los del usuario. En OpenSolaris, la biblioteca de Cestándar se encarga del subproceso múltiple para ambos gruposde interfaces.


Módulo 6 • Conceptos de programación 85

Utilice pthread_create(3C) para agregar un nuevosubproceso de control al proceso actual.

int pthread_create(pthread_t *tid, const pthread_attr_t *tattr,

void*(*start_routine)(void *), void *arg);

Para llamar a la función pthread_create() se utiliza elcomando attr, que tiene el comportamiento de estadonecesario. start_routine es la función con la que el nuevosubproceso inicia la ejecución. Cuando se devuelvestart_routine, el subproceso se cierra con el estadoconfigurado en el valor que devuelve start_routine.pthread_create() devuelve cero cuando la llamada se finalizacorrectamente. Si se devuelve cualquier otro valor, significa quese ha producido un error. Vaya a/on/usr/src/lib/libc/spec/threads.spec en OpenGrokpara obtener una lista completa de las funciones y declaracionesde pthread.

La sincronización de subprocesos permite controlar el flujo delprograma y acceder a datos compartidos para los subprocesosque estén en ejecución. Los cuatro objetos de sincronizaciónson bloqueos mutex, bloqueos de lectura/escritura, variables decondiciones y semáforos.■ Los bloqueos mutex no permiten que haya más de un

subproceso ejecutando una sección específica del código oaccediendo a determinados datos.

■ Los bloqueos de lectura/escritura permiten lecturassimultáneas y escrituras exclusivas en un recursocompartido protegido. Para modificar un recurso, unsubproceso debe adquirir primero el bloqueo de escrituraexclusivo. No se permite adquirir un bloqueo de escrituraexclusivo hasta que se hayan liberado todos los bloqueos delectura.

■ Las variables de condiciones bloquean los subprocesoshasta que una condición concreta tenga el valor true.



86

■ Los semáforos suelen coordinar el acceso a los recursos.Limitan los subprocesos que pueden tener acceso a unsemáforo. Cuando se alcanza el límite, el subproceso queintenta acceder al recurso se bloquea.

SincronizaciónLos objetos de sincronización son variables en la memoria a lasque se accede como si fueran datos. Los subprocesos dedistintos procesos pueden comunicarse entre sí a través de losobjetos de sincronización que se encuentran en la memoriacompartida controlada por los subprocesos. Los subprocesos sepueden comunicar entre sí aunque los subprocesos de distintosprocesos normalmente no se pueden ver entre sí. Los objetos desincronización también se pueden colocar en archivos. Losobjetos de sincronización pueden tener una vida útil más largaque la del proceso que los crea.

En el árbol de código fuente, podemos utilizar OpenGrok parabuscar libthread, y el segundo resultado más importante seencuentra en mutex.c, acompañado del siguiente extracto decomentario de código:

Implementation of all threads interfaces between

ld.so.1 and libthread. In a non-threaded environment

all thread interfaces are vectored to noops. When

called via _ld_concurrency() from libthread these

vectors are reassigned to real threads interfaces.

Two models are supported:

TI_VERSION == 1 Under this model libthread provides

rw_rwlock/rw_unlock, through which we vector all

rt_mutex_lock/rt_mutex_unlock calls. Under

lib/libthread these interfaces provided

_sigon/_sigoff (unlike lwp/libthread that provided

signal blocking via bind_guard/bind_clear.



TI_VERSION == 2 Under this model only libthreads

bind_guard/bind_clear and thr_self interfaces are

used. Both libthreads block signals under the

bind_guard/bind_clear interfaces. Lower level locking

is derived from internally bound _lwp_ interfaces.

This removes recursive problems encountered when

obtaining locking interfaces from libthread. The use

of mutexes over reader/writer locks also enables the

use of condition variables for controlling thread

concurrency (allows access to objects only after

their .init has completed).

Ahora que ya conoce un poco mejor cómo se definen losobjetos de sincronización en la programación de subprocesosmúltiples, veremos cómo se pueden administrar estos objetosmediante el uso de clases de planificación.

Planificación de la CPULos procesos se ejecutan en una clase de planificación con unapolítica de planificación independiente para cada clase, delmodo siguiente:

■ Realtime (RT): la clase de planificación de mayor prioridadofrece una política para los procesos que requieren unarespuesta rápida y un control absoluto por parte del usuario,o la aplicación de las prioridades de planificación. Laplanificación en tiempo real RT se puede aplicar a unproceso completo o a uno o más procesos ligeros (LWP) deun proceso. Para utilizar la clase Realtime, es necesario tenerel privilegio proc_priocntl. Consulte la página delcomando man privileges(5) para obtener másinformación.

■ System (SYS): es la clase de planificación de prioridadmedia; no se puede aplicar a un proceso del usuario.



88

■ Timeshare (TS): es la clase de planificación de prioridadmenor; viene configurada de forma predeterminada. Lapolítica TS distribuye el recurso de procesamiento de formaequitativa entre los procesos con distintas características deconsumo de CPU. Otras partes del núcleo puedenmonopolizar el procesador durante breves intervalos detiempo, sin afectar al tiempo de respuesta que obtiene elusuario.

■ Inter-Active (IA): la política IA distribuye el recurso deprocesamiento de forma equitativa entre los procesos condistintas características de consumo de la CPU, a la vez queofrece una gran capacidad de respuesta para la interaccióncon el usuario.

■ Fair Share (FSS): la política FSS distribuye el recurso deprocesamiento de forma equitativa entre los proyectos, almargen del número de procesos que tengan, especificandoshares para controlar la asignación de procesos a losrecursos de la CPU. Se recuerda el uso de los recursos, demodo que la asignación se reduce en caso de un uso elevadoy se aumenta si el uso es reducido con respecto a otrosproyectos.

■ Fixed-Priority (FX): es una política de planificaciónpreventiva de prioridad fija para los procesos que requierenque el sistema no ajuste dinámicamente las prioridades deplanificación sino que sea el usuario o la aplicación quienestienen el control de las mismas. Esta clase es un punto departida útil para controlar las políticas de asignación deCPU.

Se mantiene una clase de planificación para cada proceso ligero(LWP). Los subprocesos tienen la clase de planificación y laprioridad de sus LWP subyacentes. Cada LWP de un procesopuede tener una clase de planificación y una prioridad únicasvisibles al núcleo. Las prioridades de los subprocesos regulan lacontención de los objetos de sincronización.



Las clases de planificación RT y TS llaman a priocntl(2) paradefinir el nivel de prioridad de los procesos o de los LWP dentrode un proceso. Si utilizamos OpenGrok para buscar priocntlen la base de código, encontramos las variables que se utilizanen las clases de planificación RT y TS en el archivo rtsched.c,del modo siguiente:

27 #pragma ident "@(#)rtsched.c 1.10 05/06/08 SMI"28

29 #include "lint.h"30 #include "thr_uberdata.h"31 #include <sched.h>

32 #include <sys/priocntl.h>

33 #include <sys/rtpriocntl.h>

34 #include <sys/tspriocntl.h>

35 #include <sys/rt.h>

36 #include <sys/ts.h>

37

38 /*

39 * The following variables are used for caching information

40 * for priocntl TS and RT scheduling classs.

41 */

42 struct pcclass ts_class, rt_class;

43

44 static rtdpent_t *rt_dptbl; /* RT class parameter table */

45 static int rt_rrmin;

46 static int rt_rrmax;

47 static int rt_fifomin;

48 static int rt_fifomax;

49 static int rt_othermin;

50 static int rt_othermax;

...

Si escribimos el comando man priocntl en una ventana delterminal, se muestran los detalles de cada clase de planificacióny se describen los atributos y el uso. Por ejemplo:

% man priocntl

Reformatting page. Please Wait... done



90

User Commands priocntl(1)

NAME

priocntl - display or set scheduling parameters of specified

process(es)

SYNOPSIS

priocntl -l

priocntl -d [-i idtype] [idlist]

priocntl -s [-c class] [ class-specific options] [-

i idtype] [idlist]

priocntl -e [-c class] [ class-specific options] command

[argument(s)]

DESCRIPTION

The priocntl command displays or sets scheduling parameters

of the specified process(es). It can also be used to display

the current configuration information for the system’s pro-

cess scheduler or execute a command with specified schedul-

ing parameters.

Processes fall into distinct classes with a separate

scheduling policy applied to each class. The process classes

currently supported are the real-time class, time-sharing

class, interactive class, fair-share class, and the fixed

priority class. The characteristics of these classes and the

class-specific options they accept are described below in

the USAGE section under the headings Real-Time Class, Time-

Sharing Class, Inter-Active Class, Fair-Share Class, and

--More--(4%)



Descripción general del núcleoAhora que ya cuenta con un conocimiento avanzado de losprocesos, los subprocesos y la planificación, describiremos elnúcleo y las diferencias entre los módulos de núcleo y losprogramas de usuario. El núcleo de Solaris:

■ Administra los recursos del sistema, incluidos los sistemasde archivos, los procesos y los dispositivos físicos.

■ Ofrece a las aplicaciones servicios de sistema como laadministración de E/S, memoria virtual y planificación.

■ Coordina las interacciones de todos los procesos del usuarioy recursos del sistema.

■ Asigna prioridades y proporciona solicitudes de recursos einterrupciones y excepciones de hardware.

■ Planifica y alterna subprocesos, asigna memoria eintercambia procesos.

En la sección siguiente se abordan varias diferenciasimportantes entre los módulos de núcleo y los programas deusuario.



92

Diferencias de ejecución entre los módulos denúcleo y los programas de usuarioLas siguientes características de los módulos de núcleo sonmotivo de importantes diferencias entre la ejecución de losmódulos de núcleo y la de los programas de usuario:

■ Los módulos de núcleo tienen un espacio de direcciónindependiente. Un módulo se ejecuta en un espacio denúcleo. Una aplicación se ejecuta en un espacio de usuario.El software del sistema está protegido de los programas deusuario. El espacio de núcleo y el de usuario tienen suspropios espacios de dirección de memoria.

■ Los módulos de núcleo tienen un mayor privilegio deejecución. El código que se ejecuta en espacio de núcleotiene un mayor privilegio que el que se ejecuta en espacio deusuario.

■ Los módulos de núcleo no se ejecutan secuencialmente.Un programa de usuario suele ejecutarse de formasecuencial y lleva a cabo una única tarea de principio a fin.Un módulo de núcleo no se ejecuta secuencialmente, y seregistra para dar respuesta a futuras solicitudes.

■ Los módulos de núcleo pueden interrumpirse. Más de unproceso puede solicitar el módulo de núcleo de formasimultánea. Por ejemplo, un control de interrupción puedesolicitar el módulo de núcleo al mismo tiempo que dichomódulo está respondiendo a una llamada del sistema. En unsistema de multiprocesador simétrico (SMP), el módulo denúcleo puede ejecutar una o más CPU de forma simultánea.

■ Los módulos de núcleo deben ser previsibles. No puedesuponer que el código del módulo de núcleo es seguro sóloporque el código del controlador no se bloquea. Configureel controlador para que pueda preverse el comportamientodel módulo.



■ Los módulos de núcleo pueden compartir datos. No esnecesario que los diferentes subprocesos de un programa deaplicación compartan los datos. Las rutinas y estructuras dedatos que constituyen un controlador son comunes a todoslos subprocesos que utilizan el controlador. El controladordebe poder resolver los problemas de contención derivadosde múltiples solicitudes. Diseñe cuidadosamente lasestructuras de datos del controlador para mantenerseparados los diferentes subprocesos de ejecución.

Diferencias estructurales entre los módulos denúcleo y los programas de usuarioLas siguientes características de los módulos de núcleo sonmotivo de importantes diferencias entre la estructura de losmódulos de núcleo y la de los programas de usuario:

■ Los módulos de núcleo no definen un programaprincipal. Estos módulos, incluidos los controladores dedispositivos, no tienen ninguna rutina main(). Los módulosde núcleo son grupos de subrutinas y datos.

■ Los módulos de núcleo sólo se vinculan con el núcleo. Nose vinculan en las mismas bibliotecas en que se vinculan losprogramas de usuario. Las únicas funciones a las que puedellamar un módulo de núcleo son las que exporta el núcleo.

■ Los módulos de núcleo utilizan diferentes archivos deencabezado. Los módulos de núcleo requieren un grupodiferente de archivos de encabezado que el que necesitan losprogramas de usuario. Los archivos de encabezadonecesarios se enumeran en la página del comando man decada función. Los módulos de núcleo pueden incluirarchivos de encabezado que comparten los programas deusuario si las interfaces de usuario y núcleo dentro de dichosarchivos de encabezado compartidos se definencondicionalmente utilizando la macro _KERNEL.



94

■ Los módulos de núcleo deben evitar las variables globales.Evitar las variables globales en los módulos de núcleo esincluso más importante que evitar las variables globales enlos programas de usuario. Siempre que sea posible, declarelos símbolos como static. Cuando deba utilizar símbolosglobales, asígneles un prefijo que sea exclusivo en el núcleo.También se recomienda utilizar este prefijo para lossímbolos exclusivos del módulo.

■ Los módulos de núcleo se pueden personalizar según elhardware. Pueden dedicar registros de proceso a rolesespecíficos. El código de núcleo se puede optimizar para unprocesador concreto. Asimismo, en OpenSolaris es posiblepersonalizar las bibliotecas para algunas de las plataformasx86/x64 y UltraSPARC más recientes. Mientras que elnúcleo puede dedicar determinados registros adeterminados roles, es posible escribir código personalizadopara las bibliotecas de usuario y para las de núcleo.

■ Los módulos de núcleo se pueden cargar y descargarsegún sea necesario. El grupo de subrutinas y datos quecomponen un controlador de dispositivos se puedencompilar en un único módulo cargable de código de objeto.Este módulo cargable se puede vincular estática odinámicamente en el núcleo y desvincularlo de él. Puedeagregar funciones al núcleo mientras el sistema estáfuncionando. Puede probar nuevas versiones delcontrolador sin necesidad de reiniciar el sistema.

Depuración de procesosLa depuración de procesos en todos los niveles de la pila dedesarrollo constituye una parte principal de la escritura de losmódulos de núcleo.

Una búsqueda completa de libthread en OpenGrok genera lossiguientes comentarios de código en el archivo mdb_tdb.c que



describen la conexión entre la depuración de variossubprocesos y el funcionamiento de mdb:

In order to properly debug multi-threaded programs,

the proc target must be able to query and modify

information such as a thread’s register set using

either the native LWP services provided by libproc (if

the process is not linked with libthread), or using

the services provided by libthread_db (if the process

is linked with libthread). Additionally, a process

may begin life as a single-threaded process and then

later dlopen() libthread, so we must be prepared to

switch modes on-the-fly. There are also two possible

libthread implementations (one in /usr/lib and one in

/usr/lib/lwp) so we cannot link mdb against

libthread_db directly; instead, we must dlopen the

appropriate libthread_db on-the-fly based on which

libthread.so the victim process has open. Finally,

mdb is designed so that multiple targets can be active

simultaneously, so we could even have *both*

libthread_db’s open at the same time. This might

happen if you were looking at two multi-threaded user

processes inside of a crash dump, one using

/usr/lib/libthread.so and the other using

/usr/lib/lwp/libthread.so. To meet these

requirements, we implement a libthread_db "cache" in

this file. The proc target calls mdb_tdb_load() with

the pathname of a libthread_db to load, and if it is

not already open, we dlopen() it, look up the symbols

we need to reference, and fill in an ops vector which

we return to the caller. Once an object is loaded, we

don’t bother unloading it unless the entire cache is

explicitly flushed. This mechanism also has the nice

property that we don’t bother loading libthread_db

until we need it, so the debugger starts up faster.



96

Se pueden utilizar los siguientes comandos mdb para acceder alos LWP de un programa de varios subprocesos:

■ $l Imprime el ID del LWP del subproceso representativo siel destino es un proceso de usuario.

■ $L Imprime los ID de cada LWP del destino si dicho destinoes un proceso de usuario.

■ pid ::attach Se adjunta a los procesos utilizando el pid o elID de proceso.

■ ::release Libera el archivo principal o proceso adjuntadopreviamente. El proceso puede continuarse posteriormentemediante prun(1) o reanudarse mediante la aplicación deMDB u otro depurador.

■ dirección ::context Contexto pertinente al procesoespecificado. Estos comandos para definir puntos deinterrupción condicionales a menudo resultan de granutilidad.

■ [ addr ] ::bp [+/-dDestT] [-c cmd] [-n count] sym

... Define un punto de interrupción en las ubicacionesespecificadas.

■ addr ::delete [id | all] Elimina los especificadores deeventos con el número de ID dado.

Los sondeos DTrace se construyen de modo similar a lasconsultas MDB. Proseguiremos con los ejercicios prácticos deDTrace y, a continuación, agregaremos MDB cuando ladepuración sea más compleja.



98

Introducción a DTrace

ObjetivosEl objetivo de esta práctica es introducirle a DTrace utilizando unasecuencia de sondeo para una llamada de sistema con DTrace.

Recursos adicionales■ Solaris Dynamic Tracing Guide. Sun Microsystems, Inc., 2007.■ DTrace User Guide, Sun Microsystems, Inc., 2006

7M Ó D U L O 7

99

Activación de sondeos DTrace sencillosAl finalizar el ejercicio habrá adquirido conocimientos básicossobre los sondeos DTrace.

ResumenEn primer lugar, vamos a aprender el funcionamiento deDTrace mediante la creación de varias solicitudes muy sencillascon el sondeo denominado BEGIN, que se activa cada vez queinicia una nueva solicitud de seguimiento. Puede utilizar laopción n de -dtrace(1M) para activar un sondeo utilizando sunombre de cadena.

Activación de sondeos DTrace sencillos


100

Para activar un sondeo DTracesencillo


Active el sondeo:# dtrace -n BEGIN

Después de una breve pausa, dtrace indicará que se hahabilitado un sondeo y verá una línea de salida que informaráde que se ha activado el sondeo BEGIN. Cuando vea esta salida,dtrace permanece en estado de pausa, a la espera de que seactiven otros sondeos. Como no se ha habilitado ninguno de losotros sondeos y BEGIN sólo se activa una vez, pulse Control+Cen la shell para salir de dtrace y volver al indicador de la shell:

Vuelva al indicador de la shell. Para ello, pulse Control+C:# dtrace -n BEGIN

dtrace: description ’BEGIN’ matched 1 probe

CPU ID FUNCTION:NAME

0 1 :BEGIN

^C

#

La salida indica que se ha activado el sondeo con el nombreBEGIN y tanto su nombre como el ID de entero, 1, se hanimprimido. De forma predeterminada, se muestra el nombre enforma de entero de la CPU en que se activa este sondeo. En esteejemplo, la columna de la CPU indica que el comando dtrace

se estaba ejecutando en la CPU 0 cuando se activó el sondeo.

Puede crear solicitudes de DTrace mediante númerosarbitrarios de sondeos y acciones. Vamos a crear una solicitudsencilla con dos sondeos agregando el sondeo END al comandodel ejemplo anterior. El sondeo END se activa una vez alcompletar el seguimiento.

1

2

3


Módulo 7 • Introducción a DTrace 101

Agregue el sondeo END:# dtrace -n BEGIN -n END

dtrace: description ’BEGIN’ matched 1 probe

dtrace: description ’END’ matched 1 probe

CPU ID FUNCTION:NAME 0 1 :BEGIN

^C

0 2 :END

#

El sondeo END se activa una vez al completar el seguimiento.Como puede observar, al pulsar Control+C para salir deDTrace se activa el sondeo END. DTrace informa de laactivación de este sondeo antes de salir.

4



102

Enumeración de sondeos rastreablesEl objetivo de este ejercicio es analizar los sondeos de formamás detallada y mostrar la forma de enumerar los sondeos enun sistema.

ResumenEn los ejemplos anteriores, hemos aprendido a utilizar dossencillos sondeos denominados BEGIN y END. Pero, ¿de dóndeproceden estos sondeos? Los sondeos DTrace provienen de unconjunto de módulos del núcleo denominados proveedores;cada uno de ellos realiza un tipo determinado deinstrumentación para crear sondeos. Por ejemplo, el proveedorsyscall ofrece sondeos en cada llamada del sistema; por suparte, el proveedor fbt los ofrece en cada función del núcleo.

Al utilizar DTrace, a cada proveedor se le concede laoportunidad de publicar los sondeos que puede proporcionar ala estructura de DTrace. A continuación, puede habilitar yenlazar las acciones de seguimiento a cualquiera de los sondeospublicados.

Enumeración de sondeos rastreables


Para enumerar los sondeosrastreables


Escriba el siguiente comando:# dtrace

Las opciones del comando dtrace se imprimen en la salida.

Escriba el comando dtrace con la opción -l:# dtrace -l | more

ID PROVIDER MODULE FUNCTION NAME

1 dtrace BEGIN

2 dtrace END

3 dtrace ERROR

4 lockstat genunix mutex_enter adaptive-acquire

5 lockstat genunix mutex_enter adaptive-block

6 lockstat genunix mutex_enter adaptive-spin

7 lockstat genunix mutex_exit adaptive-release

--More--

Se enumeran los sondeos disponibles en el sistema, queincluyen los datos siguientes:

■ ID: ID interno del sondeo enumerado.■ Proveedor: nombre del proveedor. Los proveedores se

utilizan para clasificar los sondeos. También es el método deinstrumentación.

■ Módulo: nombre del módulo de Unix o la biblioteca deaplicación del sondeo.

■ Función: nombre de la función en la que se encuentra elsondeo.

■ Nombre: nombre del sondeo.

1

2

3



104

Dirija el comando anterior a wcpara buscar el número total desondeos en el sistema:# dtrace -l | wc -l

30122

El número de sondeos del que tiene conocimiento el sistema seenumera en la salida. El número varía según el tipo de sistema.

Agregue una de las opciones siguientes para filtrar la lista:

■ -P para el proveedor■ -m para el módulo■ -f para la función■ -n para el nombre

Vea los siguientes ejemplos:

# dtrace -l -P lockstat


4 lockstat genunix mutex_enter adaptive-acquire

5 lockstat genunix mutex_enter adaptive-block

6 lockstat genunix mutex_enter adaptive-spin

7 lockstat genunix mutex_exit adaptive-release

Sólo se enumeran en la salida los sondeos disponibles en elproveedor lockstat.

# dtrace -l -m ufs


15 sysinfo ufs ufs_idle_free ufsinopage

16 sysinfo ufs ufs_iget_internal ufsiget

356 fbt ufs allocg entry

Sólo se enumeran en la salida los sondeos del módulo UFS.

# dtrace -l -f open


4 syscall open entry

5 syscall open return

116 fbt genunix open entry

4

5



117 fbt genunix open return

Sólo se enumeran los sondeos con el nombre de función open.

# dtrace -l -n start


506 proc unix lwp_rtt_initial start

2766 io genunix default_physio start

2768 io genunix aphysio start

5909 io nfs nfs4_bio start

El comando anterior enumera todos los sondeos cuyo nombrees start.



106

Programación en DAhora que ya tiene conocimientos básicos sobre cómo asignarun nombre a un sondeo, activarlo y enumerarlo, puede escribirla versión de DTrace del primer programa general, "Hola,mundo""

ResumenEn este ejercicio puede constatar que, además de la creación deexperimentos de DTrace en la línea de comandos, tambiénpuede escribirlos en archivos de texto utilizando el lenguaje deprogramación D.

Programación en D


Para escribir un programa DTrace


En un editor de texto, cree un archivo llamado hello.d.

Escriba su primer programa de D:BEGIN

{

trace("Hola mundo");exit(0);

}

Guarde el archivo hello.d.

Ejecute el programa utilizando la opción -sde dtrace:# dtrace -s hello.d

dtrace: script ’hello.d’ matched 1 probe

CPU ID FUNCTION:NAME

0 1 :BEGIN Hola, mundo

#

Como puede ver, dtrace imprimió el mismo resultado queantes seguido del texto "Hola, mundo". A diferencia del ejemploanterior, no ha tenido que esperar ni pulsar Control+C. Estoscambios son el resultado de las acciones especificadas en elsondeo BEGIN de hello.d. Examinemos la estructura delprograma D con más detalle para comprender lo que haocurrido.

1

2

3

4

5

Programación en D


108

DiscusiónCada programa D está formado por una serie de cláusulas; cadauna de ellas describe uno o varios de los sondeos que se van ahabilitar, y una serie de acciones opcionales que se efectuaránuna vez activado el sondeo. Estas acciones se enumeran comouna serie de instrucciones entre llaves { } a continuación delnombre del sondeo. Cada instrucción finaliza con un punto ycoma (;).

La primera instrucción utiliza la función trace() para indicarque DTrace debe registrar el argumento especificado, la cadena"Hola, mundo", al activarse el sondeo BEGIN y, a continuación,imprimirse. La segunda instrucción utiliza la función exit()

para indicar que DTrace debe detener el seguimiento y salir delcomando dtrace.

DTrace proporciona un conjunto de funciones útiles, porejemplo trace() y exit(), a las que puede llamar en susprogramas D. Para llamar a una función, debe especificar sunombre seguido de una lista de los argumentos entreparéntesis. El conjunto completo de funciones de D se describeen la Solaris Dynamic Tracing Guide.

De momento, si está familiarizado con el lenguaje deprogramación C, quizá haya observado a partir del nombre y denuestros ejemplos que el lenguaje de programación D deDTrace es muy similar a C y awk(1). De hecho, D se deriva deun gran subconjunto de C combinado con un grupo especial defunciones y variables que facilitan el seguimiento.

Si anteriormente ya ha escrito un programa en C, la mayorparte de sus conocimientos podrán aplicarse en la creación deprogramas de seguimiento en D. Por el contrario, aunquenunca haya escrito ningún programa en C, el lenguaje D resultamuy fácil de aprender. En primer lugar, por un momentodejemos a un lado las reglas del lenguaje y examinemos cómo

Programación en D


funciona DTrace. Regresaremos más adelante al aprendizaje decómo crear programas en D más interesantes.

Programación en D


110

Depuración de aplicaciones conDTrace

ObjetivosEl objetivo de este módulo es utilizar DTrace para supervisar loseventos de las aplicaciones.

Recursos adicionalesApplication Packaging Developer’s Guide. Sun Microsystems, Inc.,2005.

8M Ó D U L O 8

111

Activación de los sondeos en modo deusuario

DTrace permite agregar sondeos dinámicamente a lasfunciones de nivel de usuario. No es necesario volver a compilarel código de usuario, ni se necesitan indicadores especiales niningún reinicio. Los sondeos DTrace pueden activarse con sólollamar al proveedor.

Una descripción de sondeo tiene la siguiente sintaxis:

pid:mod:function:name

■ pid: format pid processid (por ejemplo, pid5234)■ mod: nombre de la biblioteca o a.out (ejecutable)■ function: nombre de la función■ name: entry para la entrada de funciones, y return para

el retorno de funciones

Activación de los sondeos en modo de usuario


112

Uso de DTrace con aplicacionesEn este ejercicio, aprenderá a utilizar DTrace en las aplicacionesde usuario.

ResumenEste ejercicio se basa en el uso de un ID de proceso en ladescripción del sondeo para hacer un seguimiento de laaplicación asociada. La complejidad del procedimiento vaaumentando hasta el final del ejercicio; también aumenta lacantidad y profundidad de la información sobre elcomportamiento de la aplicación que se genera.

Uso de DTrace con aplicaciones

Módulo 8 • Depuración de aplicaciones con DTrace 113

Para aplicar DTrace a gcalctool

En el menú Programas o Aplicaciones, inicie la calculadora.

Busque el ID del proceso que acaba de iniciar.# pgrep gcalctool

8198

Este número es el ID del proceso calc, que denominaremosprocid.

Siga estos pasos para crear una secuencia en D que cuente lacantidad de veces que se llama a cualquier función de laherramienta gcalctool.

a. En un editor de texto, cree un archivo llamado proc_func.d.

b. Utilice pid$1:::entry como descriptor de sondeos.

$1 es el primer argumento que se obtiene al enviar lasecuencia, y el predicado se deja vacío.

c. En la sección de acción, agregue un elemento para contar lacantidad de veces que se llama a la función mediante lainstrucción agregada @[probefunc]=count().pid$1:::entry

{

@[probefunc]=count();

}

d. Ejecute la secuencia que acaba de escribir.# dtrace -qs proc_func.d procid

Sustituya procid con el ID de proceso de gcalctool

e. Realice un cálculo con la calculadora.

1

2

3



114

f. Pulse Control+C en la ventana en que ejecutó la secuenciaen D.

Nota – La secuencia de DTrace obtiene los datos y espera a que elusuario detenga la obtención pulsando Control+C. Si nonecesita imprimir la agregación obtenida, DTrace la imprimiráautomáticamente.

A continuación, modifique la secuencia para que solamentecuente las funciones de la biblioteca libc.

a. Copie proc_func.d en proc_libc.d.

b. Modifique la descripción del sondeo del archivoproc_libc.d y cámbiela a:pid$1:libc::entry

c. La nueva secuencia debe tener el aspecto siguiente:pid$1:libc::entry

{ @[probefunc]=count();

}

A continuación, ejecute la secuencia.# dtrace -qs proc_libc.d procid


a. Realice un cálculo con la calculadora.

b. Pulse Control+C en la ventana en que ejecutó la secuenciaen D para ver la salida.

4

5



Por último, modifique la secuencia para averiguar el tiempo quese ha destinado a cada función.

a. Cree un archivo y asígnele el nombre func_time.d.

Utilizaremos dos descripciones de sondeo en func_time.d.

b. Escriba el primer sondeo del siguiente modo:pid$1:::entry

c. Escriba el segundo del siguiente modo:pid$1:::return

d. En la sección de acción del primer sondeo, guardetimestamp en la variable ts.

La indicación de hora es un elemento integrado de DTraceque cuenta el número de nanosegundos desde un punto enel pasado.

e. En la sección de acción del segundo sondeo, calcule losnanosegundos que han transcurrido utilizando laagregación siguiente:@[probefunc]=sum(timestamp - ts)

f. La nueva secuencia func_time.ddebe coincidir con lasiguiente:

pid$1:::entry

{ ts = timestamp;

}

pid$1:::return /ts/

{ @[probefunc]=sum(timestamp - ts);

}

Ejecute la nueva secuencia func_time.d:# dtrace -qs func_time.d procid

6

7



116


a. Realice un cálculo con la calculadora.

b. Pulse Control+C en la ventana en que ejecutó la secuenciaen D para ver la salida.

^C

gdk_xid__equal 2468

_XSetLastRequestRead 2998

_XDeq 3092

...

La columna izquierda muestra el nombre de la función; laderecha, el tiempo dedicado a dicha función. El tiempo se mideen nanosegundos.



118

Depuración de aplicaciones C++con DTrace

ObjetivosLos ejemplos de este módulo muestran el uso de DTrace paradiagnosticar errores de aplicación C++. Estos ejemplos también seutilizan para comparar DTrace con otras herramientas dedepuración de aplicaciones, como Sun Studio 10 o mdb.

9M Ó D U L O 9

119

Uso de DTrace para perfilar y depurar unprograma en C++

Se creó el programa de muestra CCtest para mostrar un errorcomún a las aplicaciones en C++: la pérdida de memoria. Enmuchos casos, la pérdida de memoria tiene lugar cuando se creaun objeto, pero nunca se destruye, tal como ocurre con elprograma de este módulo.

Al depurar un programa en C++, el compilador puedeconvertir algunos nombres de C++ en cadenas mezcladas dedígitos y caracteres apenas inteligibles. Esta mezcla del nombrees un detalle de implementación necesario para admitir lasobrecarga de funciones de C++, proporcionar nombresexternos válidos para las funciones de C++ que incluyencaracteres especiales, y distinguir las instancias del mismonombre declaradas en distintos espacios de nombres y clases.

Por ejemplo, el uso de nm para extraer la tabla de símbolos de unprograma de muestra llamado CCtest produce el resultadosiguiente:

# /usr/ccs/bin/nm CCtest

...

[61] | 134549248| 53|FUNC |GLOB |0 |9 |__1cJTestClass2T5B6M_v_

[85] | 134549301| 47|FUNC |GLOB |0 |9 |__1cJTestClass2T6M_v_

[76] | 134549136| 37|FUNC |GLOB |0 |9 |__1cJTestClass2t5B6M_v_

[62] | 134549173| 71|FUNC |GLOB |0 |9 |__1cJTestClass2t5B6Mpc_v_

[64] | 134549136| 37|FUNC |GLOB |0 |9 |__1cJTestClass2t6M_v_

[89] | 134549173| 71|FUNC |GLOB |0 |9 |__1cJTestClass2t6Mpc_v_

[80] | 134616000| 16|OBJT |GLOB |0 |18 |__1cJTestClassG__vtbl_

[91] | 134549348| 16|FUNC |GLOB |0 |9 |__1cJTestClassJClassName6kM_pc_

...

Uso de DTrace para perfilar y depurar un programa en C++


120

Nota – El código fuente y el archivo MAKE de CCtest seincluyen al final de este módulo.

A partir de esta salida, puede suponer correctamente que unaserie de estos símbolos mezclados se asocia con una clasedenominada TestClass, pero no puede determinar fácilmentesi estos símbolos se asocian con constructores, destructores ofunciones de clase.

El compilador de Sun Studio incluye las tres utilidadessiguientes, que sirven para traducir los símbolos mezclados asus equivalentes en C++: nm -C, dem, and c++filt.

Nota – Aquí se utiliza el software Sun Studio 10, pero losejemplos se han probado con Sun Studio 9 y 10.

Si la aplicación en C++ se ha compilado con gcc/g++, tambiéncuenta con la posibilidad de volver a componer la aplicación.Además de c++filt, que reconoce los nombres mezclados deSun Studio y GNU, el código abierto gc++filt encontrado en/usr/sfw/bin se puede utilizar para volver a componer lossímbolos de la aplicación en g++.

Ejemplos: Símbolos de Sun Studio sin c++filt:

# nm CCtest | grep TestClass

[65] | 134549280| 37|FUNC |GLOB |0 |9 |__1cJTestClass2t6M_v_

[56] | 134549352| 54|FUNC |GLOB |0 |9 |__1cJTestClass2t6Mi_v_

[92] | 134549317| 35|FUNC |GLOB |0 |9 |__1cJTestClass2t6Mpc_v_

...

Símbolos de Sun Studio con c++filt:

# nm CCtest | grep TestClass | c++filt

[65] | 134549280| 37|FUNC |GLOB |0 |9 |TestClass::TestClass()


Módulo 9 • Depuración de aplicaciones C++ con DTrace 121

[56] | 134549352| 54|FUNC |GLOB |0 |9 |TestClass::TestClass(int)

[92] | 134549317| 35|FUNC |GLOB |0 |9 |TestClass::TestClass(char*)

...

Símbolos de g++ sin gc++filt:

[86] | 134550070| 41|FUNC |GLOB |0 |12 |_ZN9TestClassC1EPc

[110] | 134550180| 68|FUNC |GLOB |0 |12 |_ZN9TestClassC1Ei

[114] | 134549984| 43|FUNC |GLOB |0 |12 |_ZN9TestClassC1Ev

...

Símbolos de g++ con gc++filt:

# nm gCCtest | grep TestClass | gc++filt

[86] | 134550070| 41|FUNC |GLOB |0 |12 |TestClass::TestClass(char*)



...

Y, finalmente, símbolos con nm -C:


[__1cJTestClass2t6M_v_]

[87] | 134549424| 70|FUNC |GLOB |0 |9 |TestClass::TestClass(const char*)

[__1cJTestClass2t6Mpkc_v_]


[__1cJTestClass2t6Mi_v_]

Esta información permite crear una secuencia de DTrace paraagregar en las llamadas a objetos asociadas con nuestroprograma de prueba. Podemos utilizar el proveedor pid deDTrace para activar los sondeos asociados con nuestrossímbolos en C++ mezclados.

Para probar la teoría de constructor/destructor, empezaremosefectuando los siguientes recuentos:

■ El número de objetos creados -- llamadas a new()■ El número de objetos destruidos --llamadas a delete()



122

Utilice la siguiente secuencia para extraer los símbolos quecorresponden a las funciones new() y delete() del programaCCtest:

# dem ‘nm CCtest | awk -F\| ’{ print $NF; }’‘ | egrep "new|delete"

__1c2k6Fpv_v_ == void operator delete(void*)

__1c2n6FI_pv_ == void*operator new(unsigned)

La secuencia de DTrace correspondiente se utiliza para activarlos sondeos en new() y delete() (guardado como CCagg.d):

#!/usr/sbin/dtrace -s

pid$1::__1c2n6FI_pv_:

{

@n[probefunc] = count();

}

pid$1::__1c2k6Fpv_v_:

{

@d[probefunc] = count();

}

END

{

printa(@n);

printa(@d);

}

Inicie el programa CCtest en una ventana; a continuación,ejecute la secuencia que acaba de crear en otra ventana, delmodo siguiente:

# dtrace -s ./CCagg.d ‘pgrep CCtest‘ | c++filt

La salida de DTrace se dirige a través de c++filt para volver acomponer los símbolos de C++, tomando en consideración lasiguiente advertencia.



Precaución – No puede salir de la secuencia de DTrace con ^C,como lo haría normalmente, porque c++filt se podríadesconectar junto con DTrace y no se obtendría ninguna salida.Para ver la salida de este comando, vaya a otra ventana delsistema y escriba:

# pkill dtrace

Utilice esta secuencia de pasos para el resto de los ejercicios:

Ventana 1:

# ./CCtest

Ventana 2:

# dtrace -s scriptname | c++filt

Ventana 3:

# pkill dtrace

La salida de la secuencia de agregación de la ventana 2 deberíatener el siguiente formato:

void*operator new(unsigned) 12

void operator delete(void*) 8

Quizá estemos en lo cierto al afirmar que estamos creando másobjetos de que los borramos.

A continuación, comprobaremos las direcciones de memoriade los objetos e intentaremos hacer coincidir las instancias denew() y delete(). Las variables del argumento DTrace seutilizan para mostrar las direcciones asociadas con los objetos.Como el valor de retorno de new() contiene un puntero alobjeto, veremos el mismo valor de puntero que arg0 en la



124

llamada a delete(). Tras haber realizado una ligeramodificación en nuestra secuencia inicial, a continuación sepresenta la siguiente secuencia, denominada CCaddr.d:


#pragma D option quiet

/*



*/

/* return from new() */

pid$1::__1c2n6FI_pv_:return

{

printf("%s: %x\n", probefunc, arg1);

}

/* call to delete() */ pid$1::__1c2k6Fpv_v_:entry

{


}

Ejecute esta secuencia:

# dtrace -s ./CCaddr.d ‘pgrep CCtest‘ | c++filt

Espere unos instantes y escriba lo siguiente en la ventana 3:

# pkill dtrace

Nuestra salida parece un patrón de repetición de tres llamadas anew() y dos llamadas a delete():

void*operator new(unsigned): 809e480

void*operator new(unsigned): 8068a70

void*operator new(unsigned): 809e4a0

void operator delete(void*): 8068a70

void operator delete(void*): 809e4a0



Al examinar la salida que se repite, puede verse un patrón.Parece que el primer new() del patrón de repetición no tieneninguna llamada correspondiente a delete(). Llegados a estepunto, hemos identificado el origen de la pérdida de memoria.

Continuemos con DTrace para ver qué más puede obtenerse deesta información. Todavía no conocemos el tipo de claseasociada con el objeto creado en la dirección 809e480. Lainclusión de una llamada a ustack() en la entrada a new() esuna pista. A continuación se incluye la modificación a nuestrasecuencia anterior, que ahora se denomina CCstack.d:


#pragma D option quiet

/*



*/

pid$1::__1c2n6FI_pv_:entry

{

ustack();

}

pid$1::__1c2n6FI_pv_:return

{


}

pid$1::__1c2k6Fpv_v_:entry

{


}

Ejecute CCstack.d en la ventana 2 y escriba pkilldtrace en laventana 3 para imprimir la salida siguiente:

# dtrace -s ./CCstack.d ‘pgrep CCtest‘ | c++filt



126

libCrun.so.1‘void*operator new(unsigned)

CCtest‘main+0x19CCtest‘0x8050cda

void*operator new(unsigned): 80a2bd0


CCtest‘main+0x57CCtest‘0x8050cda

void*operator new(unsigned): 8068a70


CCtest‘main+0x9aCCtest‘0x8050cda

void*operator new(unsigned): 80a2bf0

void operator delete(void*): 8068a70

void operator delete(void*): 80a2bf0

Los datos ustack() indican que se llama a new() desdemain+0x19, main+0x57 y main+0x9a. Nos interesa el objetoasociado con la primera llamada a new(), en main+0x19.

Con el fin de determinar el tipo de constructor al que se llamaen main+0x19, podemos utilizar mdb del modo siguiente:

# gcore ‘pgrep CCtest‘

gcore: core.1478 dumped

# mdb core.1478

Loading modules: [ libc.so.1 ld.so.1 ]

> main::dis

main: pushl %ebp

main+1: movl %esp,%ebp

main+3: subl $0x38,%esp

main+6: movl %esp,-0x2c(%ebp)

main+9: movl %ebx,-0x30(%ebp)

main+0xc: movl %esi,-0x34(%ebp)

main+0xf: movl %edi,-0x38(%ebp)

main+0x12: pushl $0x8

main+0x14: call -0x2e4 <PLT=libCrun.so.1‘__1c2n6FI_pv_>



main+0x19: addl $0x4,%esp

main+0x1c: movl %eax,-0x10(%ebp)

main+0x1f: movl -0x10(%ebp),%eax

main+0x22: pushl %eax

main+0x23: call +0x1d5 <__1cJTestClass2t5B6M_v_>

...

El constructor recibe el nombre de la llamada al nuevo desfasemain+0x23. De este modo, hemos identificado una llamada alconstructor __1cJTestClass2t5B6M_v_ que nunca se destruye.El uso de dem para volver a componer este símbolo produce:

# dem __1cJTestClass2t5B6M_v_

__1cJTestClass2t5B6M_v_ == TestClass::TestClass #Nvariant 1()

Una llamada a la nueva TestClass() de main+0x19 es la causade la pérdida de memoria. Al examinar el archivo de origenCCtest.cc, encontramos:

...

t = new TestClass();

cout << t->ClassName();

t = new TestClass((const char *)"Hello.");cout << t->ClassName();

tt = new TestClass((const char *)"Goodbye.");cout << tt->ClassName();

delete(t);

delete(tt);

...

El primer uso de la variable t = new TestClass(); losobrescribe el segundo uso: t = new TestClass((const char

*)"Hello.");. Se ha identificado la pérdida de memoria y sepuede implementar una corrección.



128

El proveedor pid de DTrace permite activar un sondeo encualquier instrucción asociada con un proceso que se estéexaminando. Este ejemplo pretende modelizar el enfoque deDTrace para la depuración de procesos interactivos. Lasfunciones de DTrace utilizadas en este ejemplo son:agregaciones, visualización de valores de retorno y argumentosde funciones, y visualización de la pila de llamadas del usuario.Se han utilizado los comandos dem y c++filt del software SunStudio y gc++filt en gcc para extraer los sondeos de funcionesde la tabla de símbolos del programa y mostrar la salida deDTrace en un formato compatible con el origen. Archivos deorigen creados para este ejemplo:

EJEMPLO 9–1 TestClass.h

class TestClass

{

public:

TestClass();

TestClass(const char *name);

TestClass(int i);

virtual ~TestClass();

virtual char *ClassName() const;

private:

char *str;

};

TestClass.cc:

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <unistd.h>

#include "TestClass.h"

TestClass::TestClass() {

str=strdup("empty.");}



EJEMPLO 9–1 TestClass.h (Continuación)

TestClass::TestClass(const char *name) {

str=strdup(name);

}

TestClass::TestClass(int i) {

str=(char *)malloc(128);

sprintf(str, "Integer = %d", i);

}

TestClass::~TestClass() {

if ( str )

free(str);

}

char *TestClass::ClassName() const {

return str;

}

EJEMPLO 9–2 CCtest.cc

#include <iostream.h>

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include "TestClass.h"

int main(int argc, char **argv)

{

TestClass *t;

TestClass *tt;

while (1) {

t = new TestClass();


t = new TestClass((const char *)"Hello.");



130

EJEMPLO 9–2 CCtest.cc (Continuación)


tt = new TestClass((const char *)"Goodbye.");cout << tt->ClassName();

delete(t);

delete(tt);

sleep(1);

}

}

EJEMPLO 9–3 Archivo MAKE

OBJS=CCtest.o TestClass.o

PROGS=CCtest

CC=CC

all: $(PROGS)

echo "Done."

clean:

rm $(OBJS) $(PROGS)

CCtest: $(OBJS)

$(CC) -o CCtest $(OBJS)

.cc.o:

$(CC) $(CFLAGS) -c $<



132

Gestión de memoria con DTracey MDB

ObjetivosEn este módulo utilizaremos lo que ha aprendido sobre el uso deDTrace para observar los procesos examinando un fallo de página.A continuación, incorporaremos depuración de bajo nivel conMDB para localizar el problema en el código.

Recursos adicionalesSolaris Modular Debugger Guide Sun Microsystems, Inc., 2007.

10M Ó D U L O 1 0

133

Gestión de memoria del softwareLa gestión de memoria de OpenSolaris utiliza estructuras desoftware denominadas segmentos para gestionar la memoriavirtual de los procesos, así como el núcleo. La mayoría de lasestructuras de datos del software de gestión de memoria sedefinen en /usr/include/vm/*.h. En este módulo,examinaremos el código y las estructuras de datos que seutilizan para controlar los fallos de las páginas.

Gestión de memoria del software


134

Uso de DTrace y MDB para examinar lamemoria virtual

El objetivo de este ejercicio es examinar un fallo de página conDTrace y MDB.

ResumenEmpezaremos con una secuencia de DTrace para rastrear lasacciones de un único fallo de página de un proceso concreto. Lasecuencia imprime la dirección virtual del usuario que provocael fallo; a continuación, rastrea cada una de las funciones a lasque se llama desde el momento del fallo hasta que se devuelve elcontrol del fallo de la página. Utilizaremos la salida de lasecuencia para determinar el código fuente que se debeexaminar para obtener más información.

Nota – En este módulo, hemos agregado texto a la salida decódigo extensiva para guiar el ejercicio. Busque el símbolo<---- para localizar el texto asociado en la salida.

Uso de DTrace y MDB para examinar la memoria virtual

Módulo 10 • Gestión de memoria con DTrace y MDB 135

Uso de DTrace en un fallo de páginapara un proceso único


Cree un archivo llamado pagefault.d con la secuenciasiguiente:#!/usr/sbin/dtrace -s

#pragma D option flowindent

pagefault:entry

/execname == $$1/

{

printf("fault occurred on address = %p\n", args[0]);

self->in = 1;

}

pagefault:return

/self->in == 1/

{

self->in = 0;

exit(0);

}

entry

/self->in == 1/

{

}

return

/self->in == 1/

{

}

Ejecute la secuencia en Mozilla.

1

2

3



136

Nota – Debe especificar mozilla-bin como nombre delejecutable, ya que mozilla no coincide exactamente con elnombre. Se activan las afirmaciones, de modo que verá variasllamadas a, por ejemplo, mutex_owner(), que sólo se utiliza conASSERT(). Las afirmaciones se activan sólo para los núcleos dedepuración.

# ./pagefault.d mozilla-bin

dtrace: script ’./pagefault.d’ matched 42626 probes

CPU FUNCTION

0 -> pagefault fault occurred on address = fb985ea2

0 | pagefault:entry <-- i86pc/vm/vm_machdep.c or sun4/vm/vm_dep.c

0 -> as_fault <-- generic address space fault common/vm/vm_as.c

0 -> as_segat

0 -> avl_find <-- segments are in AVL tree

0 -> as_segcompar <-- search segments for segment

0 <- as_segcompar <-- containing fault address

0 -> as_segcompar <-- common/vm/vm_as.c

0 <- as_segcompar

0 -> as_segcompar

0 <- as_segcompar

0 -> as_segcompar

0 <- as_segcompar

0 -> as_segcompar

0 <- as_segcompar

0 -> as_segcompar

0 <- as_segcompar

0 -> as_segcompar

0 <- as_segcompar

0 -> as_segcompar

0 <- as_segcompar

0 <- avl_find

0 <- as_segat

0 -> segvn_fault<-- segment containing fault is found, (not SEGV)

<-- common/vm/seg_vn.c

0 -> hat_probe <-- look for page table entry for page



<-- i86pc/vm/hat_i86.c or sfmmu/vm/hat_sfmmu.c

0 -> htable_getpage <-- page tables are hashed on x86

0 -> htable_getpte <-- i86pc/vm/htable.c

0 -> htable_lookup

0 <- htable_lookup

0 -> htable_va2entry

0 <- htable_va2entry

0 -> x86pte_get <-- return a page table entry

0 -> x86pte_access_pagetable

0 -> hat_kpm_pfn2va

0 <- hat_kpm_pfn2va

0 <- x86pte_access_pagetable

0 -> x86pte_release_pagetable

0 <- x86pte_release_pagetable

0 <- x86pte_get

0 <- htable_getpte

0 <- htable_getpage

0 -> htable_release

0 <- htable_release

0 <- hat_probe

0 -> fop_getpage <-- file operation to retrieve page(s)

0 -> ufs_getpage<--file in ufs fs(common/fs/ufs/ufs_vnops.c)

0 -> bmap_has_holes <-- check for sparse file

0 <- bmap_has_holes

0 -> page_lookup <-- check for page already in memory

0 -> page_lookup_create <-- common/vm/vm_page.c

0 <- page_lookup_create <-- create page if needed

0 <- page_lookup

0 -> ufs_getpage_miss <-- page wasn’t in memory

0 -> bmap_read <-- get block number of page from inode

0 -> bread_common

0 -> getblk_common

0 <- getblk_common

0 <- bread_common

0 <- bmap_read

0 -> pvn_read_kluster <-- read pages (common/vm/vm_pvn.c)

0 -> page_create_va <-- create some pages

0 <- page_create_va

0 -> segvn_kluster

0 <- segvn_kluster



138

0 <- pvn_read_kluster

0 -> pageio_setup <-- setup page(s) for io common/os/bio.c

0 <- pageio_setup

0 -> lufs_read_strategy <-- logged ufs read

0 -> bdev_strategy <-- read device common/os/driver.c

0 -> cmdkstrategy <-- common disk driver (cmdk(7D))

<-- common/io/dktp/disk/cmdk.c

0 -> dadk_strategy <-- direct attached disk (dad(7D))

<-- for ide disks(common/io/dktp/dcdev/dadk.c)

<-- driver sets up dma and starts page in

0 <- dadk_strategy

0 <- cmdkstrategy

0 <- bdev_strategy

0 -> biowait <-- wait for pagein complete common/os/bio.c

0 -> sema_p <-- wakeup sema_v from completion interrupt

0 -> swtch <-- let someone else run(common/disp/disp.c)

0 -> disp <-- dispatch to next thread to run

0 <- disp

0 -> resume <-- actual switching occurs here

<-- intel/ia32/ml/swtch.s

0 -> savectx <-- save old context

0 <- savectx

<-- someone else is running here...

0 -> restorectx <-- restore context (we’re awakened)

0 <- restorectx

0 <- resume

0 <- swtch

0 <- sema_p

0 <- biowait

0 -> pageio_done <-- undo pageio_setup

0 <- pageio_done

0 -> pvn_plist_init

0 <- pvn_plist_init

0 <- ufs_getpage_miss <-- page is in memory

0 <- ufs_getpage

0 <- fop_getpage

0 -> segvn_faultpage <-- call hat to load pte(s) for page(s)

0 -> hat_memload

0 -> page_pptonum <-- get page frame number

0 <- page_pptonum



0 -> hati_mkpte <-- build page table entry

0 <- hati_mkpte

0 -> hati_pte_map <-- locate entry in page table

0 -> x86_hm_enter

0 <- x86_hm_enter

0 -> hment_prepare

0 <- hment_prepare

0 -> x86pte_set <-- fill in pte into page table

0 -> x86pte_access_pagetable

0 -> hat_kpm_pfn2va

0 <- hat_kpm_pfn2va

0 <- x86pte_access_pagetable

0 -> x86pte_release_pagetable

0 <- x86pte_release_pagetable

0 <- x86pte_set

0 -> hment_assign

0 <- hment_assign

0 -> x86_hm_exit

0 <- x86_hm_exit

0 <- hati_pte_map

0 <- hat_memload

0 <- segvn_faultpage

0 <- segvn_fault

0 <- as_fault

0 <- pagefault

#

Tenga en cuenta que la salida anterior se ha reducido. En unnivel más elevado, ha ocurrido lo siguiente con el fallo depágina:

■ Se llama a la rutina pagefault() para controlar los fallos depágina.

■ La rutina pagefault() llama a as_fault() para controlarlos fallos de un espacio de dirección específico.



140

■ as_fault() recorre el árbol AVL de estructuras seg enbusca de un segmento que contenga la dirección con el fallo.Si no lo encuentra, se envía al proceso la señal SIGSEGV(violación de segmentación).

■ Si se encuentra, se llama a un control de fallos específico delsegmento. Para la mayoría de los segmentos, essegvn_fault().

■ segvn_fault() busca la página con el fallo que ya esté en lamemoria. Si la página ya existe pero se ha liberado, seexcluye de la lista libre. Si la página no existe aún, esnecesario asignarla. En este caso, la página no se encuentratodavía en la memoria, de modo que se llama aufs_getpage().

■ ufs_getpage() busca los números de bloque de las páginasdel sistema de archivos llamando a bmap_read().

■ A continuación, se llama a una rutina de estrategia delcontrolador de dispositivos. Consulte strategy(9E) paraver una descripción general de las tareas que lleva a cabo larutina de estrategia.

■ Mientras se lee la página, se bloquea el subproceso quegenera el fallo de página (se apaga) mediante una llamada aswtch(). En este punto, se ejecutan otros subprocesos.

■ Una vez completada la E/S de paginación, el control deinterrupción del controlador del disco activa el subprocesomozilla-bin bloqueado.

■ El controlador del disco devuelve segvn_fault() a travésdel código del sistema de archivos.

■ A continuación, segvn_fault() llama asegvn_faultpage().

■ segvn_faultpage() llama a la capa HAT (HardwareAddress Translation) para cargar la tabla de páginaentry(s) (PTE) para la página.



■ En este punto, la dirección virtual que ha ocasionado el fallode página debe asignarse a una página física válida. Cuandose devuelve pagefault(), se volverá a intentar lainstrucción que causa el fallo de página, que ahora deberállevarse a cabo correctamente.

Utilice mdbpara examinar las estructuras de datos del núcleo ylocalice la página de la memoria física que corresponde al fallode la forma que se indica a continuación:

a. Abra una ventana de terminal.

b. Busque el número de segmentos que utiliza Mozillamediante pmap:# pmap -x ‘pgrep mozilla-bin‘ | wc

368 2730 23105

#

El resultado muestra que hay 368 segmentos.

Nota – La búsqueda del segmento que contiene la direccióndel fallo ha encontrado el segmento correcto después de 8segmentos. Consulte las llamadas a as_segcompar en lasalida de DTrace más arriba. El uso del árbol AVL acorta labúsqueda.

c. Utilice mdbpara localizar el segmento que contiene ladirección del fallo.

Nota – Si desea continuar, puede utilizar: ::log/tmp/logfile en mdb y luego !vi /tmp/logfile pararealizar la búsqueda. Asimismo, puede ejecutar mdb en unbúfer del editor.

4



142

# mdb -k

Loading modules: [ unix krtld genunix specfs dtrace

ufs ip sctp usba random fctl s1394

nca lofs crypto nfs audiosup sppp cpc fcip ptm ipc ]

> ::ps !grep mozilla-bin <-- find the mozilla-bin process

R 933 919 887 885 100 0x42014000 ffffffff81d6a040 mozilla-bin

> ffffffff81d6a040::print proc_t p_as | ::walk seg | ::print struct seg

<-- Lots of output has been omitted... -->

{

s_base = 0xfb800000 <-- the seg we want, fault addr (fb985ea2)

s_size = 0x561000 <-- greater/equal to base and < base+size

s_szc = 0

s_flags = 0

s_as = 0xffffffff828b61d0

s_tree = {

avl_child = [ 0xffffffff82fa7920, 0xffffffff82fa7c80 ]

avl_pcb = 0xffffffff82fa796d

}

s_ops = segvn_ops

s_data = 0xffffffff82d85070

}

<-- and lots more output omitted -->

> ffffffff82d85070::print segvn_data_t <-- from s_data

{

lock = {

_opaque = [ 0 ]

}

segp_slock = {

_opaque = [ 0 ]

}

pageprot = 0x1

prot = 0xd

maxprot = 0xf

type = 0x2

offset = 0

vp = 0xffffffff82f9e480 <-- points to a vnode_t

anon_index = 0

amp = 0 <-- we’ll look at anonymous space later



vpage = 0xffffffff82552000

cred = 0xffffffff81f95018

swresv = 0

advice = 0

pageadvice = 0x1

flags = 0x490

softlockcnt = 0

policy_info = {

mem_policy = 0x1

mem_reserved = 0

}

}

> ffffffff82f9e480::print vnode_t v_path

v_path = 0xffffffff82f71090

"/usr/sfw/lib/mozilla/components/libgklayout.so"

> fb985ea2-fb800000=K <-- offset within segment

185ea2 <-- rounding down gives 185000 (4kpage size)

> ffffffff82f9e480::walk page !wc <-- walk list of pages on vnode_t

1236 1236 21012 <-- 1236 pages,(not all are necessarily valid)

> ffffffff82f9e480::walk page | ::print page_t<-- walk pg list on vnode

<-- lots of pages omitted in output -->

{

p_offset = 0x185000 <-- here is matching page

p_vnode = 0xffffffff82f9e480

p_selock = 0

p_selockpad = 0

p_hash = 0xfffffffffae21c00

p_vpnext = 0xfffffffffaca9760

p_vpprev = 0xfffffffffb3467f8

p_next = 0xfffffffffad8f800

p_prev = 0xfffffffffad8f800

p_lckcnt = 0

p_cowcnt = 0

p_cv = {

_opaque = 0

}



144

p_io_cv = {

_opaque = 0

}

p_iolock_state = 0

p_szc = 0

p_fsdata = 0

p_state = 0

p_nrm = 0x2

p_embed = 0x1

p_index = 0

p_toxic = 0

p_mapping = 0xffffffff82d265f0

p_pagenum = 0xbd62 <-- the page frame number of page

p_share = 0

p_sharepad = 0

p_msresv_1 = 0

p_mlentry = 0x185

p_msresv_2 = 0

}

<-- and lots more output omitted -->

> bd62*1000=K <-- multiple page frame number time page size (hex)

bd62000 <-- here is physical address of page

> bd62000+ea2,10/K <-- dump 16 64-bit hex values at physical address

0xbd62ea2: 2ccec81ec8b55 e8575653f0e48300 32c3815b00000000

5d89d46589003ea7 840ff6850c758be0 e445c7000007df

1216e8000000 dbe850e4458d5650 7d830cc483ffeeea

791840f00e4 c085e8458904468b 500c498b088b2474

8b17eb04c483d1ff e8458de05d8bd465 c483ffeeeac8e850

458b0000074ce904

> bd62000+ea2,10/ai <-- data looks like code, let’s try dumping as code

0xbd62ea2:

0xbd62ea2: pushq %rbp

0xbd62ea3: movl %esp,%ebp

0xbd62ea5: subl $0x2cc,%esp

0xbd62eab: andl $0xfffffff0,%esp

0xbd62eae: pushq %rbx



0xbd62eaf: pushq %rsi

0xbd62eb0: pushq %rdi

0xbd62eb1: call +0x5 <0xbd62eb6>

0xbd62eb6: popq %rbx

0xbd62eb7: addl $0x3ea732,%ebx

0xbd62ebd: movl %esp,-0x2c(%rbp)

0xbd62ec0: movl %ebx,-0x20(%rbp)

0xbd62ec3: movl 0xc(%rbp),%esi

0xbd62ec6: testl %esi,%esi

0xbd62ec8: je +0x7e5 <0xbd636ad>

0xbd62ece: movl $0x0,-0x1c(%rbp)

> ffffffff81d6a040::context <--change context from kernel to mozilla-bin

debugger context set to proc ffffffff81d6a040, the address of process

> fb985ea2,10/ai <-- and dump from faulting virtual address

0xfb985ea2:

0xfb985ea2: pushq %rbp <-- looks like a match

0xfb985ea3: movl %esp,%ebp

0xfb985ea5: subl $0x2cc,%esp

0xfb985eab: andl $0xfffffff0,%esp

0xfb985eae: pushq %rbx

0xfb985eaf: pushq %rsi

0xfb985eb0: pushq %rdi

0xfb985eb1: call +0x5 <0xfb985eb6>

0xfb985eb6: popq %rbx

0xfb985eb7: addl $0x3ea732,%ebx

0xfb985ebd: movl %esp,-0x2c(%rbp)

0xfb985ec0: movl %ebx,-0x20(%rbp)

0xfb985ec3: movl 0xc(%rbp),%esi

0xfb985ec6: testl %esi,%esi

0xfb985ec8: je +0x7e5 <0xfb9866ad>

0xfb985ece: movl $0x0,-0x1c(%rbp)

> 0::context

debugger context set to kernel

> ffffffff81d6a040::print proc_t p_as <-- get as for mozilla-bin

p_as = 0xffffffff828b61d0



146

> fb985ea2::vtop -a ffffffff828b61d0 <-- check our work

virtual fb985ea2 mapped to physical bd62ea2 <--physical address matches

Una vez encontrado el segmento, se imprime la estructurasegvn_data. En este segmento, vnode_t asigna los datos delsegmento. vnode_t contiene una lista de páginas que"pertenecen" a vnode_t. Localizamos la páginacorrespondiente al desplazamiento del segmento. Cuandose localiza page_t, se obtiene el número de imagen de lapágina. A continuación, el número de imagen de la páginase convierte en una dirección física y se examinan algunosdatos de la dirección. Estos datos son código. Se compruebala dirección física utilizando el comando vtop (virtual afísico) mdb.

d. Información adicional: recorra las tablas de página delproceso para ver cómo una dirección virtual se convierte enuna dirección física.



148

Depuración de controladorescon DTrace

ObjetivosEl objetivo de este módulo es aprender a utilizar DTrace paradepurar los proyectos de desarrollo de controladores estudiandoun caso.

11M Ó D U L O 1 1

149

Asignación de puertos al controladorsmbfsde Linux al sistema operativoSolaris

Este caso se centra en el uso de la función de DTrace para eldesarrollo de controladores de dispositivos.

Desde siempre, la depuración de un controlador de dispositivosha requerido que los desarrolladores utilicen llamadas afunciones como cmn_err() para registrar la información dediagnóstico en el archivo /var/adm/messages. Esta ardua tareaimplica realizar suposiciones, volver a compilar y reiniciar elsistema para descubrir errores de código del software. Losdesarrolladores con conocimientos de lenguaje ensambladorpueden utilizar adb para crear módulos personalizados en Cpara que mdb diagnostique los errores de software. Sin embargo,el enfoque que siempre se ha dado al desarrollo y la depuracióndel núcleo resulta muy lento.

DTrace ofrece un método abreviado para realizar diagnósticos.En lugar de tener que buscar en el archivo /var/adm/messages

o las páginas de salida truss, se puede utilizar DTrace paracapturar información únicamente en los eventos que desee verel desarrollador. Veamos algunos ejemplos para ilustrar mejorlas ventajas de DTrace.

En primer lugar, cree una plantilla de controlador smbfs basadaen el controlador nfs de Sun. Tras la compilación correcta delcontrolador, compruebe que se pueda cargar y descargar sinproblemas. En primer lugar, copie el controlador de prototipoen /usr/kernel/fs e intente aplicar modload manualmente:

# modload /usr/kernel/fs/smbfs

can’t load module: Out of memory or no room in system tables

El archivo /var/adm/messages contiene:

Asignación de puertos al controlador smbfs de Linux al sistema operativo Solaris


150

genunix: [ID 104096 kern.warning] WARNING: system call missing

from bind file

Al buscar el mensaje que indica que falta la llamada al sistema,vemos que se encuentra en la función mod_getsysent() en elarchivo modconf.c, en una llamada fallida a mod_getsysnum. Enlugar de buscar manualmente en el flujo de mod_getsysnum()de los archivos de origen uno a uno, a continuación se incluyeuna secuencia de DTrace sencilla para permitir todos loseventos de entrada y retorno en el proveedor fbt (FunctionBoundary Tracing) una vez se ha especificado mod_getsynum().



fbt::mod_getsysnum:entry

/execname == "modload"/{

self->follow = 1;

}

fbt::mod_getsysnum:return

{

self->follow = 0;

trace(arg1);

}

fbt:::entry

/self->follow/

{

}

fbt:::return

/self->follow/

{

trace(arg1);

}


Módulo 11 • Depuración de controladores con DTrace 151

Nota – trace(arg1) muestra el valor de retorno de la función.

Al ejecutar esta secuencia y ejecutar el comando modload enotra ventana, se obtiene la salida siguiente:

# ./mod_getsysnum.d

dtrace: script ’./mod_getsysnum.d’ matched 35750 probes

CPU FUNCTION

0 -> mod_getsysnum

0 -> find_mbind

0 -> nm_hash

0 <- nm_hash 41

0 -> strcmp

0 <- strcmp 4294967295

0 -> strcmp

0 <- strcmp 7

0 <- find_mbind 0

0 <- mod_getsysnum 4294967295

El causante es find_mbind() que devuelve '0', o nm_hash() quedevuelve '41'. Si examinamos rápidamente find_mbind(),veremos que un valor de retorno de 0 indica un estado de error.Al ver el origen de find_mbind() en/usr/src/uts/common/os/modsubr.c, vemos que estamosbuscando una cadena char en una tabla de hash. Acontinuación, mostraremos el contenido de la cadena debúsqueda y la tabla de hash utilizando DTrace.

Para ver el contenido de la cadena de búsqueda, agregamos unseguimiento strcmp() a la secuencia mod_getsysnum.danterior:

fbt::strcmp:entry

{



152

printf("name:%s, hash:%s", stringof(arg0),

stringof(arg1));

}

Éstos son los resultados de nuestro próximo intento de cargar elcontrolador:

# ./mod_getsysnum.d

dtrace: script ’./mod_getsysnum.d’ matched 35751 probes

CPU FUNCTION

0 -> mod_getsysnum

0 -> find_mbind

0 -> nm_hash

0 <- nm_hash 41

0 -> strcmp

0 | strcmp:entry name:smbfs,

hash:timer_getoverrun

0 <- strcmp 4294967295

0 -> strcmp

0 | strcmp:entry name:smbfs,

hash:lwp_sema_post

0 <- strcmp 7

0 <- find_mbind 0

0 <- mod_getsysnum 4294967295

Estamos buscando smbfs en una tabla de hash y no seencuentra. ¿Cómo se coloca smbfs en esta tabla de hash? Sivolvemos a find_mbind(), observamos que la variablesb_hashtab de la tabla de hash se pasa a la función nm_hash()

que falla.

Una búsqueda rápida en el código fuente muestra quesb_hashtab se inicia con una llamada a read_binding_file(),que toma como argumentos un archivo config, la tabla de hashy un puntero a función. Al seguir explorando el código fuente,veremos que el contenido del archivo config se define como/etc/name_to_sysnum en el archivo/usr/src/uts/common/os/modctl.c. Al parecer, hemosolvidado incluir una entrada de configuración para el



controlador. Agregue lo siguiente al archivo/etc/name_to_sysnum y reinicie.

’smbfs 177’

(read_binding_file() is read once at boot time.)

Tras reiniciar, el controlador se puede cargar correctamente.

# modload /usr/kernel/fs/smbfs

Compruebe que el controlador esté cargado con el comandomodinfo:

# modinfo | grep smbfs

160 feb21a58 351ac 177 1 smbfs (SMBFS syscall,client,comm)

160 feb21a58 351ac 24 1 smbfs (network filesystem)

160 feb21a58 351ac 25 1 smbfs (network filesystem version 2)

160 feb21a58 351ac 26 1 smbfs (network filesystem version 3)

Nota – Recuerde que este controlador se basa en una plantillanfs, que explica esta salida.

Asegúrese de que también pueda descargar el módulo:

# modunload -i 160

can’t unload the module: Device busy

Esto se debe probablemente a un valor de retorno EBUSY errno.Dado que el controlador smbfs es un módulo cargado, tenemosacceso a todas las funciones de smbfs:

# dtrace -l fbt:smbfs:: | wc -l

1002

Sorprendente. Sin necesidad de código especial, ahora tenemosacceso a la entrada 1002 y los eventos de retorno que contiene elcontrolador. Estos controles de la función 1002 permiten



154

depurar el trabajo sin necesidad de ninguna versión especial de"código instrumentado" del controlador. A continuación,supervisaremos todas las llamadas smbfs cuando se llama amodunload, utilizando esta secuencia de DTrace sencilla:



fbt:smbfs::entry

{

}

fbt:smbfs::return

{

trace(arg1);

}

Parece que modunload no puede acceder al código smbfs.Utilicemos DTrace para buscar en modunload con estasecuencia:



fbt::modunload:entry

{

self->follow = 1;

trace(execname);

trace(arg0);

}

fbt::modunload:return

{

self->follow = 0;

trace(arg1);

}



fbt:::entry

/self->follow/

{

}

fbt:::return

/self->follow/

{

trace(arg1);

}

Here’s the output of this script:

# ./modunload.d

dtrace: script ’./modunload.d’ matched 36695 probes

CPU FUNCTION

0 -> modunload modunload 160

0 | modunload:entry

0 -> mod_hold_by_id

0 -> mod_circdep

0 <- mod_circdep 0

0 -> mod_hold_by_modctl

0 <- mod_hold_by_modctl 0

0 <- mod_hold_by_id 3602566648

0 -> moduninstall

0 <- moduninstall 16

0 -> mod_release_mod

0 -> mod_release

0 <- mod_release 3602566648

0 <- mod_release_mod 3602566648

0 <- modunload 16

Observe que el valor de retorno EBUSY '16' procede demoduninstall. Examinemos el código fuente de moduninstall.moduninstall devuelve EBUSY en algunas ubicaciones, demodo que tomaremos en consideración las siguientesposibilidades:



156

1. if (mp->mod_prim || mp->mod_ref ||

mp->mod_nenabled != 0) return (EBUSY);

2. if ( detach_driver(mp->mod_modname) != 0 ) return

(EBUSY);

3. if ( kobj_lookup(mp->mod_mp, "_fini") == NULL )

4. A failed call to smbfs _fini() routine

No es posible acceder directamente a todas estas posibilidades,pero las abordaremos mediante un proceso de eliminación.Utilizaremos la secuencia siguiente para ver el contenido de lasdiferentes estructuras y valores de retorno de moduninstall:



fbt::moduninstall:entry

{

self->follow = 1;

printf("mod_prim:%d\n",((struct modctl *)arg0)->mod_prim);

printf("mod_ref:%d\n",((struct modctl *)arg0)->mod_ref);

printf("mod_nenabled:%d\n",((struct modctl *)arg0)->mod_nenabled);

printf("mod_loadflags:%d\n",((struct modctl *)arg0)->mod_loadflags);

}

fbt::moduninstall:return

{

self->follow = 0;

trace(arg1);

}

fbt::kobj_lookup:entry

/self->follow/

{



}

fbt::kobj_lookup:return

/self->follow/

{

trace(arg1);

}

fbt::detach_driver:entry

/self->follow/

{

}

fbt::detach_driver:return

/self->follow/

{

trace(arg1);

}

This script produces the following output:

# ./moduninstall.d

dtrace: script ’./moduninstall.d’ matched 6 probes

CPU FUNCTION

0 -> moduninstall

mod_prim:0

mod_ref:0

mod_nenabled:0

mod_loadflags:1

0 -> detach_driver

0 <- detach_driver 0

0 -> kobj_lookup

0 <- kobj_lookup 4273103456

0 <- moduninstall 16

Al comparar esta salida con el código, vemos que el fallo no sedebe a los valores de la estructura mp o los valores de retorno dedetach_driver() de kobj_lookup(). Por tanto, si seguimos unproceso de eliminación, debe ser el estado devuelto mediante la



158

llamada status = (*func)();, que llama a la rutina smbfs

_fini(). Éste es el contenido de la rutina smbfs _fini():

int _fini(void)

{

/* don’t allow module to be unloaded */

return (EBUSY);

}

Al cambiar el valor de retorno a '0' y volver a compilar el códigose obtiene un controlador que podemos cargar y descargar, porlo que habremos completado el objetivo de este ejercicio. Enestos ejemplos hemos utilizado exclusivamente el proveedorFunction Boundary Tracing. Tenga en cuenta que fbt es sólouno de los múltiples proveedores de DTrace.



160

Recursos de OpenSolaris

Para obtener más información, asistencia y formación, utilice losrecursos siguientes.

■ Documentación de la comunidad:http://opensolaris.org/os/community/documentation

■ Documentación de Sun:http://www.sun.com/documentation

■ Asistencia de Sun: http://www.sun.com/support■ Formación de Sun: Sun ofrece una gama completa de opciones

de formación y certificación profesional de Solaris paraayudarle a aplicar esta potente plataforma y conseguir unmayor éxito en sus operaciones. Para obtener informaciónadicional sobre la formación de Solaris,visite:http://www.sun.com/training/catalog/operating_systems/index.xml

AA P É N D I C E A

161

http://opensolaris.org/os/community/documentation

http://www.sun.com/documentation

http://www.sun.com/support

http://www.sun.com/training/catalog/operating_systems/index.xml

http://www.sun.com/training/catalog/operating_systems/index.xml

162

Documents

Introducciónalos sistemasoperativos:uso delproyectoOpenSolarisprofesores.fi-b.unam.mx/sun/Downloads/Solaris/OpenSolaris... · 2018-07-12 · Introducciónalos sistemasoperativos:uso