Voir la source de Projet système : environnement

{{Maintenance uniquement par enseignants}}
Le projet système se déroule dans les salles affectées (cf. l'emploi du temps). La [[Media:Psys_plateforme.pdf|présentation]] détaille l'environnement. Ici, nous précisons la configuration des logiciels. Dans le cadre du projet de spécialité 2A système, nous conseillons fortement l'utilisation de Qemu pour les cycles de développement. Parfois vous aurez aussi avantage à utiliser Bochs, particulièrement lors de l'implantation de la pagination. 

== Conseil ==

Laisser tourner un noyau en machine virtuelle peut vite consommer beaucoup de ressources processeur, ce qui fait chauffer la machine de développement et peut faire "ramer" votre environnement. Il est donc conseillé d'arrêter les machines virtuelles après utilisation.

Il est possible de réduire au minimum la consommation processeur en utilisant l'instruction HLT à l'intérieur des boucles d'attente active. HLT a pour effet de mettre en pause le processeur jusqu'à ce qu'une interruption matérielle survienne. En général on entoure l'instruction HLT des instructions STI et CLI.

 __asm__ __volatile__("sti");
 __asm__ __volatile__("hlt");
 __asm__ __volatile__("cli");

ou en utilisant les fonctions ASM fournies  dans <tt>cpu.h</tt>
 sti();
 halt();
 cli();

== Qemu ==
Qemu est un logiciel complexe fournissant, entre autre, une machine virtuelle basée sur KVM. L'idée de cette page est de présenter l'utilisation de Qemu/KVM dans le cadre du Projet Système.

=== Installation ===
Qemu devrait normalement être disponible sur les machine Ensilinux de l'école. Sur vos machines personnelles, il suffit d'installer les paquetages <code>qemu</code> et <code>qemu-kvm</code> pour obtenir Qemu et le support KVM. Pour les personnes qui auraient une distribution un peu moins clefs en main qu'Ubuntu, n'oubliez pas d'ajouter votre utilisateur au groupe <code>kvm</code>.

Pour les utilisateurs d'Ubuntu:
 sudo apt-get install qemu qemu-kvm qemu-common
Pour ceux d'Archlinux:
 sudo pacman -S qemu
Vous pouvez compléter avec les commandes pour d'autres distributions/gestionnaires de paquets.

=== Cas d'utilisation ===
Le noyau du projet système se lance très simplement avec Qemu. Notre noyau respecte le standard Multiboot qui lui permet d'être chargé aveuglément par un loader supportant ce format, or Qemu sait charger sans aide un noyau au format Multiboot. Ainsi lancer le noyau consiste simplement à lancer la commande suivante:
<code>qemu-system-i386 -m 256 -kernel kernel/kernel.bin</code>
* <code>-m <valeur></code> précise la taille de la mémoire vive disponible en Mo.
* <code>-kernel <chemin vers un binaire></code> indique le binaire du noyau à lancer.

'''Notes : '''
* le noyau ne peut pas fonctionner correctement avec moins de 256 Mo de mémoire vive.
* sur certaines distributions il faudra peut être remplacer <code>qemu-system-i386</code> par <code>qemu-kvm</code>, tout simplement <code>qemu</code> ou encore <code>qemu-system-x86_64</code>. Les arguments de la ligne de commande restent identiques.

==== CentOS 6.5 de l'école ====
 /usr/libexec/qemu-kvm -m 256 -kernel kernel/kernel.bin
 VNC server running on `::1:5900'
et
 vinagre [::1]:5900
Les crochets viennent de la notation d'adresse IPv6 dans une URL

=== Affichage VGA sous CentOS ===

Qemu est capable de gèrer l'affichage (pour nous l'écran VGA) de plusieurs façons:
* directement dans une fenêtre graphique classique (sdl ou gtk)
* dans un fenêtre texte (en mode VGA) (curses)
* ou en utilisant spice (le même protocole que "pcvirtuel") ou vnc. Il faut alors utiliser un client d'affichage. Sous CentOS, par exemple, vous pouvez utiliser <tt>vinagre</tt>
  vinagre localhost:6666


=== Débug ===
Qemu fourni un certain nombre d'outils embarqués pour débugguer facilement le programme qu'il fait tourner. Cette section n'est pas exhaustive, vous êtes invités à lire la manpage de Qemu et/ou à compléter cette page si vous connaissez des astuces de débug supplémentaires.

==== Connecter un débuggueur ====
Pour connecter un débuggueur à un noyau, il est nécessaire que celui-ci fournisse un minimum d'outils. Ce sont les gdb-stubs, ils sont disponibles sur le site de gdb. Le point intéressant avec Qemu, c'est qu'il implémente déjà de tels stubs et il n'est pas nécessaire que le noyau le supporte lui même.

Pour les utiliser et connecter le débuggueur, il faut lancer votre noyau de la manière suivante:
 qemu-system-i386 -m 256 -kernel kernel/kernel.bin -s -S
* Les options <code>-m</code> et <code>-kernel</code> sont documentées plus haut.
* <code>-s</code> démarre un serveur gdb sur le port TCP 1234.
* <code>-S</code> bloque le vCPU tant que le débuggueur n'est pas connecté et commande la machine.

'''Note pour kvm (accélération matérielle)''': le qemu de la Ubuntu utilise l'accélération matérielle (kvm) par défaut. Celui de la Debian utilise kvm avec l'option <code>-enable-kvm</code>.Les breakpoints classiques (<code>break</code>) fonctionnent mal avec kvm. Vous pouvez utilisez les hbreak, les breakpoints assistés par le matériel (ici c'est qemu, le "matériel"). Par exemple pour mettre un breakpoint sur la fonction kernel_start
 (gdb) hbreak kernel_start 
 Hardware assisted breakpoint 1 at 0x1126fd: file start.c, line 14.
 (gdb) cont
 Continuing.
 
 Breakpoint 1, kernel_start () at start.c:14
 14	{
 (gdb)

''' CentOS 6.5 de l'école ''':
Il faut désactiver l'accélération (kvm) et utiliser un démarrage avec le boot.pxe (pseudo-carte réseau) pour pouvoir faire des breakpoints. Il faut donc récupérer le fichier boot.pxe du ZIP fournit en PSE.

Il '''FAUT''' se placer dans le répertoire avec le fichier kernel.bin (il sera chargé par le boot.pxe):
 qemu-system-i386 -m 256 --s -S -no-kvm -net nic -net user,tftp=`pwd`,bootfile=boot.pxe

Mais qemu sans kvm devient alors plus permissif que le vrai matériel. Certains bugs n'apparaîtront pas.

==== utiliser le débogueur ====

Qemu est bloqué pour le moment, il vous reste à démarrer <code>gdb</code> (ou <code>ddd</code>):
 $ gdb kernel/kernel.bin
 GNU gdb (GDB) 7.6
 [...]
 Reading symbols from /home/dejeand/psys/kernel/kernel.bin...done.
 (gdb)
puis à le connecter à la VM:
 (gdb) target remote :1234
 Remote debugging using :1234
 0x0000fff0 in ?? ()
GDB est prêt, mettez en place vos breakpoints, watchpoints et continuez l'éxecution avec la commande <code>cont</code>.

==== Console/sortie débug ====
Une fonctionnalité intéressante de Qemu est la console de débug. Quand vous écrivez dans la mémoire de la machine pour faire de l'affichage VGA 80x25, Qemu émule la carte et vous affiche le contenu dans une fenêtre. Quand vous modifiez l'affichage (passage en mode VESA, ou en mode dessin au pixel), vous n'avez plus la possibilité d'avoir des traces.

Qemu fourni un port sur son processeur virtuel qui permet de sortir des traces directement dans le terminal. Ainsi chaque caractère émis sur ce port à l'aide d'un <code>outb</code> apparaît dans votre terminal. Vous pouvez ainsi débugguer même quand l'affichage est inutilisable. Pour l'activer, lancez qemu avec l'option <code>-debugcon stdio</code>.

'''Exemple : '''
 outb('a', 0xE9);
Fait apparaître un <code>a</code> dans votre terminal, à vous d'adapter votre <code>console_putbytes</code> pour qu'il puisse réaliser celà. Attention ce n'est qu'une possiblité de débug, non un élement requis pour l'évaluation de votre noyau.

=== Quelques options supplémentaires ===
Certaines des options qui suivent pourront vous être utile:
*<code>-no-reboot</code> quitte Qemu au lieu de redémarrer si il y a lieu (triples fautes, etc.).
*<code>-no-shutdown</code> bloque le vCPU lors d'un arrêt de la VM au lieu de rebooter, pratique pour conserver les traces en cas du bug.
*<code>-display <type></code> change le type d'affichage pour ''type'', utiliser le type ''curses'' permet d'obtenir un affichage VGA directement dans la console et non dans une fenêtre X, pratique pour une utilisation distante. Voir la manpage pour plus de détails.
*<code>-hd[abcd] <file></code> utiliser ''file'' comme disque dur n° (a=0 .. d=3).


== Clé USB ==

Il est également possible de tester votre noyau sur un vrai PC, via le chargeur Grub.

Si Grub est déjà installé sur votre clé (c'est le cas sur la clé Ensimag distribuée en 1A en septembre 2010), il suffit d'ajouter la configuration suivante dans le fichier <tt>boot/grub/grub.cfg</tt>, à adapter selon le partitionnement de la clé :
 menuentry "kernel.bin" {
 multiboot (hd0,1)/kernel.bin
 }

Sinon, nous vous proposons un programme pour installer Grub sur une clé USB. 

'''Attention''' : le script d'installation ne supporte que les clés USB munies d'une table de partition. La commande <tt>mount</tt> vous permet de savoir si c'est le cas (la présence d'un chiffre à la fin du nom de périphérique) :

 # Exemple de clé sans table de partition
 /dev/sdb on /media/disk type vfat ...
 
 # Exemple de clé avec table de partition
 /dev/sdb1 on /media/disk type vfat ...

Il est possible de reformatter une clé avec une table de partition, mais les données qu'elle contient seront perdues.

=== Installation de Grub sur la clé ===

* Brancher la clé USB sur le poste de développement
* Créer sur la clé un fichier ou un répertoire vide nommé exactement : <tt>installer_grub_ici</tt>
* Taper dans un terminal la commande : <tt>usbgrub</tt>. Cette commande va localiser votre clé USB par le fichier marqueur créé précedemment, et y installer grub dans un répertoire nommé <tt>boot</tt>.
* Supprimer le fichier <tt>installer_grub_ici</tt>

Attention : si votre clé était déjà bootable, il ne sera plus possible de démarrer le système qu'elle contient sans retravailler la configuration de grub (nous ne l'avons pas testé).

=== Tester un noyau ===

Une fois la clé bootable créée, on peut l'utiliser pour démarrer le noyau sur n'importe quel PC récent :
* Copier le fichier kernel.bin à la racine de la clé
* Déconnecter proprement (''démonter'') la clé USB
* Brancher la clé sur un PC éteint
* Démarrer le PC et faire apparaître le menu de sélection d'amorçage (F12 sur les machines de D200 / D201)
* Choisir le périphérique correspondant à la clé (''USB Device'' + ''Entrée'' en D20x)

On voit alors Grub qui affiche le menu de boot.

<!--== VirtualBox ==

VirtualBox <!-- est l'environnement de test à privilégier pour les cycles de développement. C'est le moyen le plus rapide de tester une modification de votre noyau. Il--> peut être démarré via le menu Applications -> Outils système -> Sun VirtualBox.

Note : si vous souhaitez utiliser VirtualBox sur votre machine personnelle sous Linux, il ne faut pas choisir la version OSE (''Open Source Edition'') qui n'est pas compatible avec le chargeur de noyau fourni. La [http://www.virtualbox.org/wiki/Linux_Downloads version binaire] fonctionne elle sans problème. Il faut également installer l'extension pack de VirtualBox pour avoir accès aux fonctionnalités PXE nécessaires au projet (voir la section [https://www.virtualbox.org/wiki/Downloads Download] de VirtualBox).

=== Création de la machine virtuelle ===

On crée d'abord une machine virtuelle de base.

* Nouveau -> Suivant.
* Choisir un nom pour la machine virtuelle. Nous choisissons de l'appeler '''Noyau'''. Système d'exploitation : '''Other''', version : '''Other/Unknown'''. Suivant.
* Taille de la mémoire vive : 64 Mo.
* Décocher l'option ''Disque dur d'amorçage''. La machine virtuelle n'a pas besoin de disque dur. Suivant. Continuer. Terminer.

Maintenant, on paramètre plus finement cette machine virtuelle.

* Clic droit sur '''Noyau''' -> Préférences -> Système. Tout décocher dans ''Ordre d'amorçage'' et cocher '''Réseau'''.
* Toujours dans Préférences -> Interfaces séries -> Port 1. Cocher l'activation. Port numéro : '''COM1'''. Mode port : '''Tuyau hôte'''. Cocher ''Créer un tuyau''. Port/Chemin fichier : '''/tmp/vbox-psys'''. OK.

Finalement on installe un programme ([[Media:Noyau.pxe.gz|Noyau.pxe.gz]]) nécessaire pour le boot du noyau par le réseau. C'est un chargeur intermédiaire, chargé par le BIOS de la machine virtuelle via un réseau virtuel, qui chargera lui-même votre noyau en mémoire de la machine virtuelle pour l'exécuter de manière compatible avec la ''Multiboot Specification'' (voir le manuel de Grub).

 mkdir -p ~/.VirtualBox/TFTP
 gzip -dc Noyau.pxe.gz > ~/.VirtualBox/TFTP/Noyau.pxe

=== Tester un noyau ===

Après avoir configuré la machine virtuelle comme indiqué ci-dessus, il est possible de tester un noyau en le copiant dans le répertoire TFTP.

 cp kernel.bin ~/.VirtualBox/TFTP/

Il suffit de lancer la machine virtuelle pour voir le noyau démarrer.

Pour l'arrêter, il suffit de fermer la fenêtre et de choisir l'option ''Eteindre la machine''.

=== Débogage ===

Le fichier <tt>/tmp/vbox-psys</tt> créé par VirtualBox pour le port série est une socket Unix, à laquelle gdb ne peut pas se connecter. Il faut donc la convertir en un pseudo port série. Pour cela, vous pouvez utiliser la commande socat. Après le lancement de la machine virtuelle, la commande :

 socat UNIX-CONNECT:/tmp/vbox-psys PTY,link=/tmp/gdb-psys

créera le lien symbolique <tt>/tmp/gdb-psys</tt> vers un nouveau pseudo port série, dont on peut alors se servir directement avec gdb ou ddd à la place de <tt>/dev/ttyS0</tt>.

=== Conseil ===

Laisser tourner un noyau en machine virtuelle peut vite consommer beaucoup de ressources processeur, ce qui fait chauffer la machine de développement et peut faire "ramer" votre environnement. Il est donc conseillé d'arrêter les machines virtuelles après utilisation.

Il est possible de réduire au minimum la consommation processeur en utilisant l'instruction HLT à l'intérieur des boucles d'attente active. HLT a pour effet de mettre en pause le processeur jusqu'à ce qu'une interruption matérielle survienne. En général on entoure l'instruction HLT des instructions STI et CLI.

 __asm__ __volatile__("sti");
 __asm__ __volatile__("hlt");
 __asm__ __volatile__("cli");
-->

== Bochs ==
Bochs est un émulateur x86. Contrairement à VirtualBox et Qemu, il n'éxecute pas le code directement sur le processeur quand c'est possible, mais émule ''entièrement'' le comportement du processeur, et de la machine de manière générale. L'inconvénient majeur est une grosse perte de performances, l'avantage est qu'il est possible de suivre et de tracer aboslument tous les comportements de CPU et du matériel émulé.

Cet outil est primordial pour le développement de la mémoire virtuelle car il permet à tout moment de l'éxecution:
* obtenir le mapping mémoire courant,
* tracer les fautes de pages, leur adresse et leur résolution,
* éxecuter en mode pas à pas quelque soit la situation dans le noyau, peu importe l'état des gdb-stubs par exemple.

=== Installation ===
Bochs ne sera disponible que sur vos machines personnelles, dans la mesure où il nécessite une image de disque pour fonctionner, et par conséquent les droits ''root'' pour la créer. Nous verrons ceci un peu plus loin. Il existe deux versions de Bochs dans vos dépôts, une version standard, et une version avec les outils de développement, notament le débuggueur intégré. Nous souhaitons installer cette seconde version.

Sur Ubuntu, la version proposée dans les dépôts n'est pas compilée avec le débuggueur. Il faudra donc la compiler manuellement. Pour les utilisateurs d'Archlinux, vous trouverez le package dans les dépôts ''AUR'' :
 yaourt -S aur/bochs-with-debugger

Pour les autres vous pouvez vous inspirer des commandes suivantes pour compiler votre version:
 $ cd /tmp
 $ wget http://downloads.sourceforge.net/project/bochs/bochs/2.6/bochs-2.6.tar.gz
 $ tar xzf bochs-2.6.tar.gz
 $ cd bochs-2.6/
 $ ./configure --enable-smp --enable-all-optimizations --with-all-libs --prefix=/opt --enable-debugger --enable-plugins --enable-pci --enable-pcidev --enable-usb --enable-3dnow --enable-debugger-gui

Puis, si tout s'est bien passé :
 $ make -j n
où ''n'' est jusqu'à deux fois le nombre de coeurs (threads) disponibles sur votre machine.

Enfin installez le tout (dans ''/opt'' pour garder une machine saine):
 $ sudo make install

=== Configuration pour le projet ===
Emuler un système dans bochs nécessite de mettre en place un petit environnement d'éxecution. Il consiste en un fichier de configuration et une image de disque. Nous vous fournissons le nécessaire dans les paragraphes suivants.

==== Configuration de la machine émulée ====
Bochs utilises un fichier de configuration nommé <code>bochsrc</code> qu'il cherche à l'endroit où vous lancez l'émulateur. Le fichier suivant devrait convenir pour un projet système :
<code>bochsrc</code>
 megs: 256
 boot: disk
 ata0-master: type=disk, path="disk.img", mode=flat, cylinders=260, heads=16, spt=63
Quelques explications :
# <code>megs: 256</code> quantité de mémoire alloué au système.
# <code>boot: disk</code> la machine boot à partir d'un périphérique de type disque dur.
# <code>ata0-master: type=disk [...]</code> décrit la configuration du disque dur 0, c'est un disque IDE, ayant comme base le fichier <code>disk.img</code>.

En lançant bochs dans le même répertoire que le fichier, il prendra cette configuration automatiquement, sinon vous pouvez utiliser :
 bochs -f /chemin/vers/le/fichier/bochsrc

==== Utilisation d'une image de disque ====
Comme indiqué précédement, nous allons devoir utiliser une image de disque, un fichier qui représente le contenu d'un disque dur que Bochs va présenter comme tel au système qu'il émule. En effet Bochs n'est pas capable de booter un noyau au format Multiboot comme Qemu.

Pour cela il faut créer un fichier dont le contenu sera comme indiqué ci-dessous :
* Un Master Boot Record (MBR) avec un loader et une table des partitions
* Une partition primaire avec un système de fichier contenant le binaire du noyau et le fichier de configuration du loader.
Nous avons choisi d'utiliser un système de fichiers ext2, et GRUB comme loader. Comme la construction d'une telle image peut être compliquée et peu intéressante, nous vous en fournissons une : [[Fichier:disk.img.tgz]].

Décompressez (c'est du bzip2, l'extension est mauvaise à cause du wiki) et assurez-vous de son intégrité (utilisez le hash MD5 ci-dessous) :
 $ tar xjf disk.img.tgz
 $ md5sum disk.img 
 78551d0692cc798a2624654c5fbd8fa2  disk.img
Une fois fait, placez l'image à l'endroit où vous lancerez bochs, ou modifiez le fichier de configuratioun pour qu'il pointe sur la bonne image.

Maintenant nous allons voir comment copier votre noyau dans l'image de disque afin d'utiliser l'émulateur. Pour cela il vous faudra les droits administrateurs pour monter et démonter l'image de disque. Ce qui explique pourquoi ceci ne peut avoir lieu sur les machines de l'école, l'utilisation de ''fuse-ext2'' n'ayant pas encore été explorée. La séquence suivante copie le binaire du noyau dans l'image de 
 $ mkdir -p disk/
 $ sudo mount -t ext2 -o loop,offset=1048576 disk.img disk/
 $ sudo cp kernel/kernel.bin disk/kernel.bin
 $ sync
 $ sudo umount disk/
 $ rm -r disk/

A titre d'exemple, on peut ajouter une cible pour lancer bochs dans le top-Makefile du noyau ce qui ajoute la cible suivante:
 disk:
        mkdir -p $@
 
 .PHONY: bochs
 bochs: all disk
        @echo "### This target will require root access to mont disk image ! ###"
        sudo mount -t ext2 -o loop,offset=1048576 disk.img disk/
        sudo cp kernel/kernel.bin disk/kernel.bin
        sync
        sudo umount disk/
        bochs

Il ne reste plus qu'à faire <code>make bochs</code> pour compiler puis lancer automatiquement bochs avec une image mise à jour. La seule contrainte est l'entrée du mot de passe pour <code>sudo</code>.

==== Utilisation d'une image de cdrom sans droit root ====
Il est possible de construire une image de cdrom sans avoir besoin des droits <code>root</code>

Il faut d'abord créer un répertoire (ici <code>iso</code>), y mettre kernel.bin (ici dans <code>iso/boot</code>) et un fichier de boot <code>grub.cfg</code> dans <code>iso/boot/grub/</code>
 mkdir -p iso/boot/grub
 cp kernel.bin iso/boot
 cp grub.cfg iso/boot/grub

Le fichier grub.cfg peut contenir les lignes suivantes:
 set timeout=15
 set default=0 # Set the default menu entry
 menuentry "OS projet System: kernel.bin" {
   multiboot /boot/kernel.bin   # The multiboot command replaces the kernel command
   boot
 }

La construction de l'image <code>cd.iso</code> est réalisée par grub2
 grub-mkrescue -o cd.iso iso

Le <code>bochsrc</code> suivant boot bochs sur l'image de cdrom:
 megs: 256
 boot: cdrom
 ata0-master: type=cdrom, path="cd.iso", status=inserted

=== Lancer bochs avec son débuggueur ===
Lorsque Bochs est compilé avec le débuggueur, celui-ci va arrêter automatiquement l'éxecution à chaque démarrage pour vous laisser le configurer, ajouter des breakpoints, etc. Vous allez donc obtenir :
 $ bochs
 [...]
 Next at t=0
 (0) [0x00000000fffffff0] f000:fff0 (unk. ctxt): jmp far f000:e05b         ; ea5be000f0
 00000000000i[XGUI ] Mouse capture off
 <bochs:1>
La commande <code>cont</code> vous permet de continuer l'éxecution telle quel.

Une fois l'émulation lancée, vous pouvez :
* Interrompre l'éxecution pour configurer le niveau de logs en utilisant la "boite à outils" disponible dans la fenêtre de bochs.
* Interrompre l'éxecution en faisant Ctrl+C pour obtenir le prompt. Ainsi vous configurer les points d'arrêts, les watch points, regardez les valeurs des registres, etc.
La page suivante documente à merveille l'utilisation du débuggueur intégré: [http://bochs.sourceforge.net/doc/docbook/user/internal-debugger.html Documentation du débuggueur.]

=== Astuce de débug ===
Parfois au cours de votre développement, particulièrement si vous utilisez Bochs, vous obtiendrez comme unique information, l'adresse contenue dans le pointeur d'instruction au moment de la faute. Vous pouvez exploiter cette information, si faible soit-elle.

'''Exemple : '''
La trace suivante est émise à Bochs:
 00171331842d[CPU0 ] page fault for address 00000000 @ 001472c1
et m'indique que j'ai déréférencé <code>NULL</code>, à l'adresse <code>0x001472c1</code>. Pour savoir où la faute à exactement eu lieu, je désassemble le binaire du noyau et je peux savoir dans quelle fonction se trouve cette adresse :
 $ objdump -d kernel/kernel.bin | less
 [...]
 001472b0 <kernel_start>:
     1472b0:       55                      push   %ebp
     1472b1:       89 e5                   mov    %esp,%ebp
     1472b3:       83 ec 18                sub    $0x18,%esp
     1472b6:       b8 00 00 00 00          mov    $0x0,%eax
     1472bb:       c7 00 00 00 00 00       movl   $0x0,(%eax)       <------------- ICI
     1472c1:       c7 04 24 10 28 15 00    movl   $0x152810,(%esp)
     1472c8:       e8 f7 51 00 00          call   14c4c4 <puts>
 [...]
A partir de ceci, on voit que l'on est dans la fonction ''kernel_start'', peut de temps après le début, et on repère le pattern :
 mov    $0x0,%eax
 movl   $0x0,(%eax)
typique du : <code>*((int*)0) = 0;</code> que j'ai introduit pour créer la faute. Vous vouliez faire du système, vous êtes en plein dedans.