Cette section décrit toutes les nouvelles fonctions et les améliorations de Solaris 10 3/05 en matière d'outils de développement, par rapport à la première distribution du système d'exploitation Solaris 9 en mai 2002. La fonction de suivi dynamique DTrace est particulièrement importante.
Les développeurs sont également invités à prendre connaissance de ces nouvelles fonctions dans les sections de sécurité et d'administration du système :
Cette fonction a été introduite dans la version 11/03 de Solaris Express.
La fonction Solaris DTrace est une fonction de suivi dynamique complète offrant aux utilisateurs, administrateurs et développeurs de Solaris un niveau supplémentaire d'observation du noyau et des processus utilisateur. Pour plus d'informations, reportez-vous à la section Fonction de suivi dynamique DTrace.
Cette fonction a été introduite dans la version 3/05 de Solaris 10.
GCC est le compilateur “C” Open Source de GNU Software Foundation. Les outils de développement incluent gmake, bison, binutils, gnuM4 et flex.
Ces améliorations ont été introduites dans Solaris Express 8/04.
Une nouvelle version du langage Perl (Practical Extraction and Report Language) est disponible par défaut dans Solaris 10. La nouvelle version par défaut de Perl est la version 5.8.4. Vous devez réinstaller les modules que vous avez installés manuellement après la mise à niveau du logiciel Solaris 10. Pour plus d'informations sur l'installation de modules, voir “Perl 5” dans le System Administration Guide: Network Services .
Pour plus d'informations concernant le langage Perl, consultez la page de manuel perl(1).
Ces améliorations ont été introduites dans Solaris Express 8/04.
Les commandes truss, pstack et pflags ont été mises à jour afin de permettre à l'utilisateur de spécifier des threads individuels au sein d'un processus ou d'un noyau. Les développeurs et administrateurs système peuvent ainsi mieux comprendre le comportement des grosses applications multithread, et cibler le débogage de threads particuliers.
Pour plus d'informations, reportez-vous aux pages de manuel suivantes :
Ces améliorations ont été introduites dans la version 5/04 de Solaris Express. De nouvelles interfaces de programmation ont été ajoutées dans Solaris Express 8/04.
Tous les périphériques Edgeport USB-série actuels fonctionnent désormais avec cette version de Solaris. Les périphériques USB 1.1 audio et autres périphériques isochrones fonctionnent désormais derrière les hubs à grande vitesse USB 2.0.
Ces interfaces ont été introduites dans la version 8/04 de Solaris Express.
Les interfaces de programmation USBA (Universal Serial Bus Architecture) 2.0 sont rendues publiques en tant que partie du système d'exploitation Solaris 10. Ces interfaces sont présentées sous la rubrique des fonctions et structures usb_* dans les pages de manuel sections 9F et 9S. Voir aussi Writing Device Drivers.
La structure USBA est désormais appelée USBA 2.0. Les pilotes USB écrits pour les interfaces USBA 1.0 dans les DDK précédents ne sont compatibles qu'au niveau binaire avec le logiciel Solaris 10. Ces pilotes ne sont pas compatibles au niveau de la source avec le logiciel Solaris 10.
Ces améliorations ont été introduites dans Solaris Express 8/04.
La commande ls affiche maintenant les temps fichiers avec une précision de l'ordre de la seconde ou de la nanoseconde. Consultez la rubrique Améliorations de la commande ls.
Cette fonction a été introduite dans la version 7/04 de Solaris Express.
Deux nouvelles fonctions de conversion de chaînes en entiers longs sont désormais à la disposition des développeurs de module de noyau. Les fonctions ddi_strtol() et ddi_strtoul () permettent respectivement de convertir des chaînes en entiers longs et en entiers longs sans signe. Ces nouvelles fonctions offrent souplesse au niveau de la saisie, conformité DDI et détection d'erreur améliorée.
Pour plus d'informations, reportez-vous aux pages de manuel ddi_strtol(9F) et ddi_strtoul(9F).
Cette fonction a été introduite dans la version 7/04 de Solaris Express.
La commande pstack a été améliorée afin d'afficher les trames Java lors de l'utilisation de la dernière version de Java. Pour chaque trame Java de la pile d'appels, la fonction et le numéro de ligne sont affichés s'ils sont disponibles.
Consultez la page de manuel pstack(1).
Cette fonction est toute nouvelle dans Solaris Express version 6/04.
La structure cryptographique Solaris prend désormais en charge les mécanismes suivants pour les protocoles SSL (Secure Sockets Layer) et TLS (Transport Layer Security) :
CKM_SSL3_PRE_MASTER_KEY_GEN
CKM_SSL3_MASTER_KEY_DERIVE
CKM_SSL3_KEY_AND_MAC_DERIVE
CKM_SSL3_MASTER_KEY_DERIVE_DH
CKM_TLS_PRE_MASTER_KEY_GEN
CKM_TLS_MASTER_KEY_DERIVE
CKM_TLS_KEY_AND_MAC_DERIVE
CKM_TLS_MASTER_KEY_DERIVE_DH
La structure cryptographique Solaris est une architecture permettant aux applications du système Solaris d'utiliser ou de fournir des services cryptographiques. Toutes les interactions avec la structure sont basées sur l'interface PKCS#11 Cryptographic Token Interface (Cryptoki) de RSA Laboratories, département de recherche de RSA Security, Inc.
Pour plus d'informations, reportez-vous à la rubrique “PKCS #11 Functions : C_GetMechanismList” du Solaris Security for Developers Guide .
Cette fonction est toute nouvelle dans Solaris Express version 6/04.
Les constructeurs de fournisseurs cryptographiques se connectant à la structure cryptographique Solaris disposent de plus de souplesse pour demander des certificats à Sun Microsystems. Les certificats prennent maintenant en charge les distributions d'exportation retail et nonretail.
Les produits de chiffrement retail sont ceux dont le gouvernement autorise l'expédition dans tous les pays. Toutefois, ces produits retail ne peuvent pas être expédiés dans certains pays désignés, considérés comme présentant une menace pour la sécurité par le gouvernement américain. Les produits de chiffrement nonretail sont ceux dont le gouvernement américain autorise l'usage exclusif au sein des États-Unis ou dans certains pays exonérés par le gouvernement.
Pour plus d'informations, reportez-vous à la page de manuel elfsign(1) et à l'annexe F, “Packaging and Signing Cryptographic Providers,” du Solaris Security for Developers Guide.
Cette description a été introduite dans le programme pilote de Solaris Express et mise à jour dans la version 5/04. Les mises à jour des éditeurs de liens et des bibliothèques ont également été introduites dans Solaris 9 12/02 et dans les versions suivantes. Ces mises à jour sont incluses dans la version 3/05 de Solaris 10.
La version Solaris 10 inclut des fonctions d'éditeur de liens telles que la compression de tableaux de chaînes, l'élimination de sections non référencées et la détection de dépendances non référencées. Pour des informations complètes relatives aux dernières améliorations, consultez l'annexe D, “Linker and Libraries Updates and New Features,” du Linker and Libraries Guide .
Les améliorations introduites dans Solaris Express 5/04 sont les suivantes :
Une restructuration du système de fichiers a déplacé de nombreux composants de /usr/lib vers /lib. Les chemins de recherche par défaut pour les éditeurs de lien ont été modifiés en conséquence.
Les bibliothèques d'archives du système ne sont plus fournies. La création d'un exécutable complet avec lien statique n'est donc plus possible.
L'option -A pour la commande crle offre une plus grande souplesse pour la définition des dépendances alternatives.
Les améliorations apportées dans la version précédente du programme pilote Software Express sont les suivantes :
Une plus grande souplesse pour la définition des configurations matérielles et logicielles des objets ELF est obtenue grâce aux éditeurs de liens.
L'interface d'audit de lien d'exécution la_objfilter() a été ajoutée.
Le filtrage d'objets partagés a été étendu afin de permettre un filtrage par symbole.
Un stockage local au niveau du thread est fourni.
L'option -z ignore a été étendue afin d'éliminer les sections non référencées lors d'une édition de lien. Consultez la page de manuel ld(1).
Une plus grande souplesse pour la définition de la visibilité d'un symbole est obtenue grâce à la directive mapfile “protégée”.
Les sémantiques de recherche dlopen(3DL ) et dlsym(3DL) ont été étendues avec un nouveau mode, RTLD_FIRST.
Les dépendances non référencées peuvent être déterminées à l'aide de l'utilitaire ldd. Consultez l'option -U dans la page de manuel ldd(1).
Cette fonction a été introduite dans la version 3/04 de Solaris Express.
Le système d'exploitation Solaris 10 a été amélioré afin de permettre aux modules de noyau d'effectuer des opérations d'accès aux périphériques telles que l'ouverture, la lecture ou l'écriture. Ce système vous permet également de déterminer les périphériques fournis grâce à un nouvel ensemble public d'interfaces “LDI” (Layered Driver Interfaces).
Les développeurs de pilotes peuvent faire appel aux interfaces LDI pour accéder aux périphériques en mode caractère, bloc ou STREAMS directement depuis le noyau Solaris. Les développeurs d'applications peuvent utiliser les interfaces LDI pour afficher les informations sur les couches des pilotes. Cette nouvelle architecture offre également aux administrateurs la possibilité d'examiner l'utilisation du périphérique à l'intérieur du noyau. Pour plus d'informations, consultez les pages de manuel ldi_*(9F) et di_*(3DEVINFO).
Les utilitaires prtconf et fuser ont été améliorés afin d'inclure les fonctions suivantes :
“Device Layering” par le biais de la commande prtconf : cette commande affiche le nœud mineur du périphérique et les informations relatives à l'utilisation du périphérique. Cet utilitaire indique également les nœuds mineurs ouverts par le module de noyau.
Reportez-vous à la page de manuel prtconf(1M).
“Device Usage” par le biais de la commande fuser : cette commande affiche les informations concernant les utilisateurs d'un périphérique. Cette commande indique également quel sous-système du noyau Solaris ou quel processus utilisateur ouvre un périphérique ou y accède au sein du noyau Solaris.
Reportez-vous à la page de manuel fuser(1M).
Les interfaces LDI commencent par le préfixe ldi_. Ces interfaces sont utilisées pour l'accès au périphérique et pour obtenir des informations sur le périphérique au niveau du noyau. Des pages de manuel sont fournies pour les interfaces dans la section 9F. Au niveau utilisateur, un jeu d'interfaces de bibliothèques, contenant des informations sur le périphérique, fournit des informations sur l'utilisation du périphérique dans les applications utiles à la récupération du noyau. Des pages de manuel sont fournies pour les interfaces LDI libdevinfo dans la section 3DEVINFO. En outre, les pages de manuel prtconf(1M) et fuser(1M) comprennent des informations concernant l'affichage des informations d'utilisation du périphérique du noyau fournies par l'architecture LDI.
Pour plus d'informations, reportez-vous au chapitre 13, “Layered Driver Interface (LDI),” du Writing Device Drivers .
Ces modifications ont été introduites dans la version 3/04 de Solaris Express et dans la version 9/04 de Solaris 9.
La sémantique du membre uc_stack de la structure ucontext_t a été modifiée ; elle s'applique aux entrées de la fonction de bibliothèque makecontext(3C) libc. La compatibilité binaire entre les précédentes versions de Solaris et le système Solaris 10 est préservée.
Les applications qui utilisent cette interface doivent être mises à jour avant d'être recompilées pour la version Solaris 10. Pour plus d'informations, reportez-vous à la page de manuel makecontext(3C).
Cette fonction a été introduite dans la version 2/04 de Solaris Express.
Cette version de Solaris est conforme à la spécification Single UNIX Specification, Version 3 (SUSv3). SUSv3 fournit des mises à jour de POSIX.1-1990, POSIX.1b-1993, POSIX.1c-1996, POSIX.2-1992 et POSIX.2a-1992.
Reportez-vous à la section “Single UNIX Specification, Version 3 Introduces Changes” des Notes de version Solaris 10 pour obtenir une description détaillée de l'impact des mises à jour de SUSv3 pour les utilisateurs de Solaris.
Cette fonction a été introduite dans la version 1/04 de Solaris Express.
L'API Advanced Sockets met à jour l'API Solaris Sockets de sorte qu'elle soit en conformité avec la version actuelle du document RFC 2292. Reportez-vous à la section API sockets avancée IPv6.
Cette fonction a été introduite dans la version 12/03 de Solaris Express.
La méthode SASL (Simple Authentication and Security Layer) fournit aux développeurs d'applications et de bibliothèques partagées des interfaces pour l'ajout de fonctions d'authentification, de contrôle d'intégrité des données et de chiffrement aux protocoles basés sur les connexions.
SASL se compose des éléments suivants :
une bibliothèque, libsasl, qui fournit une API pour les applications nécessitant des services d'authentification, de confidentialité et d'intégrité ;
une interface fournisseur de services (SPI) pour les plug-ins tiers afin d'ajouter de nouvelles méthodes d'authentification, des règles de normalisation des noms et des zones de stockage des propriétés ;
des fichiers d'en-têtes pour le développement ;
des plug-ins fournis par Sun pour les mécanismes suivants :
EXTERNAL
PLAIN
CRAM-MD5
DIGEST-MD5
GSS-API
GSS-SPNEGO
SASL permet au développeur d'écrire une API générique sans se préoccuper des détails de mise en œuvre des mécanismes de sécurité. Une fois développés de manière à utiliser SASL de façon adéquate, les serveurs et les clients peuvent utiliser de nouveaux mécanismes de sécurité, des plug-ins de normalisation des noms et utilisateurs et des plug-ins auxprop sans recompilation.
SASL est décrit dans RFC 2222. SASL convient particulièrement aux applications utilisant les protocoles suivants :
IMAP
SMTP
ACAP
LDAP
Pour plus d'informations sur SASL, consultez la page de manuel libsasl(3LIB) Reportez-vous également au Solaris Security for Developers Guide .
Cette fonction a été introduite dans la version 12/03 de Solaris Express.
Les ports d'événement constituent une structure permettant aux applications de générer et de collecter des événements en provenance de sources disjointes. La structure peut récupérer les événements de plusieurs objets simultanément sans altérer les performances globales.
Pour plus d'informations, reportez-vous aux pages de manuel port_create(3C) et signal.h(3HEAD).
Solaris Express version 12/03 a apporté des améliorations aux utilitaires coreadm, gcore et mdb. Reportez-vous à la rubrique Améliorations du contenu du fichier Core.
Cette fonction a été introduite dans la version 10/03 de Solaris Express et améliorée dans la version 1/06 de Solaris 10.
Les opérations atomiques fournissent dans libc des API effectuant rapidement des opérations atomiques simples. Cette nouvelle fonction permet aux applications de mettre automatiquement la mémoire à jour sans utiliser ni primitives de synchronisation ni langage d'assemblage spécifique à la plate-forme. Les opérations disponibles comprennent l'addition, la fonction booléenne “et” et la fonction booléenne “ou”.
Pour plus d'informations, reportez-vous à la page de manuel atomic_ops(3C).
La description de cette fonction a été mise à jour dans Solaris Express 9/03.
Les fichiers MOF (Managed Object Format) ont subi plusieurs modifications dans le répertoire /usr/sadm/mof.
Le fichier Solaris_VM1.0.mof est devenu Solaris_VM2.0.mof puis Solaris_VM3.0.mof.
Les classes du système de fichiers local ont été déplacées de Solaris_VM2.0.mof vers le nouveau fichier, Solaris_FS1.0.mof. Le fichier Solaris_FS1.0.mof définit les classes relatives aux périphériques de stockage.
Deux des fournisseurs, Solaris_DiskDrive et Solaris_DiskPartition, qui se trouvaient dans le fichier Solaris_VM1.0.mof, ont été déplacés vers le nouveau fichier Solaris_DMGT.1.0.mof. Le fichier Solaris_DMGT.1.0.mof contient les classes représentant les disques, les partitions de disque, ainsi que d'autres classes de gestion des périphériques.
Cette version comprend également un nouveau fichier MOF, Solaris_NFS1.0.mof. Le fichier Solaris_NFS1.0.mof définit les classes relatives aux périphériques NFS. Ce fichier contient les classes NFS de Solaris_VM2.0.mof ainsi que de nouvelles classes pour la configuration et le contrôle de partages NFS (ou “exportations”) et de montages.
Cette fonction est nouvelle dans le programme pilote de Software Express. Cette fonction est incluse dans la version 3/05 de Solaris 10.
Il n'est plus nécessaire que les processus soient exécutés en tant que root pour disposer des capacités superutilisateur. Les capacités superutilisateur peuvent à la place être partagées par les administrateurs système en tant que droits de processus discrets. Ces droits de processus sont implémentés par le biais de privilèges. Les privilèges permettent aux développeurs de réduire l'accès à des opérations limitées et de restreindre les périodes d'effet des privilèges. L'utilisation de privilèges permet de réduire les dommages qui étaient occasionnés lorsqu'un programme exécuté avec des privilèges était compromis. Pour assurer la compatibilité, les programmes non modifiés qui sont exécutés en tant que root conservent tous les privilèges.
Pour obtenir des informations générales sur les privilèges, reportez-vous à la rubrique Gestion des droits des processus. Pour plus d'informations sur la configuration et l'obtention de privilèges, reportez-vous aux pages de manuel setppriv(2) et getppriv(2). Pour plus d'informations, reportez-vous aux pages de manuel priv_str_to_set(3C) et priv_addset(3C).
Pour plus d'informations, reportez-vous au Solaris Security for Developers Guide .
Cette fonction est nouvelle dans le programme pilote de Software Express. Cette fonction est incluse dans la version 3/05 de Solaris 10.
La structure cryptographique de Solaris fournit des services cryptographiques aux applications. Les applications accèdent à la structure par le biais de libpkcs11(3LIB) et à des niveaux supérieurs.
La structure cryptographique de Solaris fournit les fonctions suivantes aux développeurs d'applications utilisant le chiffrement :
Interfaces de programmation au niveau utilisateur pour diverses fonctions cryptographiques. Ces interfaces couvrent, par exemple, le chiffrement, le déchiffrement, la synthèse des messages et la signature. La norme industrielle, RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki), sert d'API.
La structure prend en charge les algorithmes de chiffrement suivants :
AES
DES/3DES
RC4
MD5
SHA-1
DSA
RSA
D-H
Interfaces utilisateur modulables pour Sun et développeurs tiers. Ces interfaces permettent aux utilisateurs d'ajouter de nouveaux plug-ins provenant de fournisseurs d'algorithmes de chiffrement au niveau utilisateur. Les administrateurs ont la possibilité de remplacer un fournisseur existant par une implémentation différente. L'interface de fournisseur de services (SPI) utilisateur repose également de la norme PKCS#11. Les outils de signature, de mise en paquets et d'installation des fichiers binaires tiers sont fournis.
Implémentation logicielle optimisée des algorithmes de chiffrement et de signature numérique les plus utilisés tels que AES, DES/3DES et RSA. Cette implémentation est optimisée sur les plates-formes SPARC et UltraSPARC.
Outil administratif d'interface de ligne de commande, cryptoadm, pour l'ajout et la suppression de plug-ins de chiffrement, la définition d'une stratégie de sécurité et d'autres fonctions administratives. Reportez-vous à la page de manuel cryptoadm(1M).
Consultez également les pages de manuel suivantes : libpkcs11(3LIB), pkcs11_softtoken(5) et pkcs11_kernel(5). Reportez-vous aussi à la rubrique Structure cryptographique de Solaris pour les administrateurs système.
Les fournisseurs d'accélérateur cryptographique logiciel ou matériel qui souhaitent fournir des plug-ins à la structure cryptographique Solaris doivent contacter Sun Microsystems pour plus d'informations.
Cette fonction est nouvelle dans le programme pilote de Software Express. Cette fonction est incluse dans la version 3/05 de Solaris 10.
Sur le SE Solaris 10, l'empaquetage est simplifié pour la plupart des composants 32 bits et des composants 64 bits fournis dans un même package. Reportez-vous à la rubrique SPARC : modifications du package 64 bits.
Cette fonction est nouvelle dans le programme pilote de Software Express. Cette fonction est incluse dans la version 3/05 de Solaris 10.
Cette version de Solaris 10 contient un nouveau “pseudo-mécanisme” GSS-API pour la négociation de la sécurité GSS-API basée sur le protocole SPNEGO (IETF RFC 2478). Le protocole SPNEGO (Simple and Protected GSS-API Negotiation) est le plus utile pour les applications à implémentation GSS-API prenant en charge plusieurs mécanismes de sécurité. Il peut être appliqué lorsque deux applications utilisent GSS-API pour échanger des données et qu'elles ignorent quels mécanismes sont pris en charge par l'autre application.
SPNEGO est un mécanisme de pseudo-sécurité qui est représenté par l'identificateur d'objet suivant :
iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) |
SPNEGO permet aux pairs GSS-API de déterminer intra-bande si leurs références partagent les mêmes mécanismes de sécurité. Si tel est le cas, les pairs peuvent choisir un mécanisme commun pour créer l'environnement de sécurité.
Pour plus d'informations, reportez-vous aux pages de manuel mech(4) et mech_spnego(5). Reportez-vous également au Solaris Security for Developers Guide .
Cette fonction est nouvelle dans le programme pilote de Software Express et dans la version 12/03 de Solaris 9. Cette fonction est incluse dans la version 3/05 de Solaris 10.
Le Programming Interfaces Guide contient désormais un chapitre consacré aux interfaces qui interagissent avec les groupes voisins (lgroups). Ces interfaces peuvent s’utiliser pour aider une application à allouer efficacement les ressources de la CPU et de la mémoire. Cette fonctionnalité améliore les résultats de certains systèmes.
Cette fonction est nouvelle dans le programme pilote de Software Express. Cette fonction est incluse dans la version 3/05 de Solaris 10.
L'utilitaire pmap libelle désormais les piles de threads afin de simplifier leur identification.
Reportez-vous à la page de manuel pmap(1) pour plus d'informations.
Cette fonction est nouvelle dans le programme pilote de Software Express. Cette fonction est incluse dans la version 3/05 de Solaris 10.
Un nouvel indicateur, DOOR_REFUSE_DESC, a été ajouté à la fonction door_create. () Ce nouvel indicateur simplifie l'écriture pour les serveurs frontaux qui n'acceptent pas les descripteurs d'argument.
Pour plus d'informations, reportez-vous à la page de manuel door_create(3DOOR).
Cette fonction est nouvelle dans le programme pilote de Software Express et dans la version 4/03 de Solaris 9. Cette fonction est incluse dans la version 3/05 de Solaris 10.
Les API de contrôle des piles permettent une interaction évoluée avec prise en charge du compilateur de contrôle de pile disponible dans Sun ONE Studio. Ces API doivent être utilisées dans des applications dont la compilation s'effectue avec le contrôle des piles activé, et qui gèrent leurs propres piles ou essaient de détecter leurs propres dépassements de piles.
Les développeurs assurant la maintenance de leur propre bibliothèque de threads doivent utiliser l'interface setustack de manière à ce que la fonction de contrôle des piles soit activée lorsque les clients de leur bibliothèque effectuent des compilations.
Reportez-vous aux pages de manuel stack_getbounds(3C), stack_setbounds(3C) et stack_inbounds(3C).
Cette fonction est nouvelle dans le programme pilote de Software Express et dans la version 12/02 de Solaris 9. Cette fonction est incluse dans la version 3/05 de Solaris 10.
Ces versions incluent de nouvelles extensions de la fonction crypt () et introduisent la fonction crypt_gensalt. () Ces améliorations permettent aux administrateurs de modifier l'algorithme utilisé pour masquer les mots de passe de connexion UNIX des utilisateurs.
Des modules MD5 et Blowfish sont également inclus : les modules MD5, situés dans les fichiers crypt_sunmd5 et crypt_bsdmd5 ; et le module Blowfish, dans le fichier crypt_bsdbf.
Les développeurs peuvent créer de nouveaux modules pour les algorithmes de masquage de mots de passe secondaires. Il est conseillé aux développeurs d'applications d'utiliser la fonction crypt_gensalt() plutôt que de générer manuellement le saut pour passer à la fonction crypt().
Les modules des algorithmes secondaires sont spécifiés dans le fichier crypt.conf(4) Le champ module_path spécifie le chemin d'accès vers l'objet d'une bibliothèque partagée qui implémente les deux fonctions requises suivantes :
crypt_gensalt_impl() : génère le saut.
crypt_genhash_impl() : génère le mot de passe chiffré.
Pour de plus amples informations, reportez-vous aux pages de manuel crypt(3C) et policy.conf(4).
Cette fonction est nouvelle dans le programme pilote de Software Express et dans la version 12/02 de Solaris 9. Cette fonction est incluse dans la version 3/05 de Solaris 10.
La fonction madvise() permet au noyau d'optimiser l'accès à une région de la mémoire définie par l'utilisateur. Cette version de Solaris 9 inclut trois nouveaux indicateurs pour la fonction madvise() :
MADV_ACCESS_LWP : donne priorité à l'allocation de ressources d'un processus léger (LWP) spécifié.
MADV_ACCESS_MANY : spécifie une plage d'adresses que les processus utilisent de façon intensive dans la machine.
MADV_ACCESS_DEFAULT : restaure les paramètres par défaut d'un modèle d'accès vers une plage d'adresses.
Pour de plus amples informations sur la fonction madvise(), consultez la page de manuel madvise(3C).
Cette fonction est nouvelle dans le programme pilote de Software Express et dans la version 4/03 de Solaris 9. Cette fonction est incluse dans la version 3/05 de Solaris 10.
libumem est une bibliothèque d'allocation de mémoire en mode utilisateur (non noyau). Elle permet de déboguer les fuites de mémoire et autres aberrations qui impliquent l'utilisation de la mémoire.
Cette fonction s'utilise comme un utilitaire d'allocation ABI (interface binaire d'application) standard tel que malloc. () Une application en mode utilisateur demande un nombre aléatoire d'octets de mémoire et un pointeur contenant l'adresse de la mémoire allouée est ensuite retourné.
Pour plus d'informations, reportez-vous à la page de manuel libumem(3LIB).
Cette fonction a été introduite dans le programme pilote de Software Express et dans la version 8/03 de Solaris 9. Cette fonction est incluse dans la version 3/05 de Solaris 10.
Les interfaces à carte intelligente Solaris sont un ensemble d'interfaces publiques pour les terminaux à carte intelligente. Les fournisseurs de terminaux à carte peuvent implémenter ces interfaces dans une bibliothèque partagée au niveau de l'utilisateur afin d'assurer une prise en charge au niveau du périphérique de leurs terminaux à carte intelligente dans Solaris. L'ensemble des interfaces de terminaux à carte intelligente Solaris est basé sur des interfaces à carte intelligente qui font partie de la structure Linux Smartcard. Les bibliothèques de prise en charge des terminaux à carte de Linux peuvent être aisément portées vers Solaris. Pour plus d'informations sur les cartes à puce, reportez-vous au Solaris Smartcard Administration Guide .
Cette fonction est nouvelle dans le programme pilote de Software Express et dans la version 9/02 de Solaris 9. Cette fonction est incluse dans la version 3/05 de Solaris 10.
La structure Smartcard Solaris propose désormais des API middleware de bas niveau qui permettent d'échanger des données avec une carte à puce par l'intermédiaire d'un lecteur de cartes à puce. Il est possible d'utiliser ces API sur des plates-formes telles que les systèmes Sun BladeTM et Sun Ray. TM Les applications en langage Java ou C peuvent utiliser ces interfaces.
Pour plus d'informations, reportez-vous à la page de manuel libsmartcard(3LIB) et aux JavaDocs dans /usr/share/javadoc/smartcard. Consultez également le Solaris Smartcard Administration Guide .