Je me pose la question de savoir jusqu'à quel point le Hardware Abstraction
Layer est, justement, une abstraction ?
La définition que j'ai trouvé est "A thin layer of software *provided by
the Hardware Manufacturer* that hides, or abstracts, Hardware differences
from higher layers of the Operating System".
Le terme qui me gêne est justement le fait que ce soit le constructeur qui
fournisse le HAL. Cela veut-il simplement dire que par exemple pour qu'un
nouveau bus soit supporté il faut que le constructeur du bus fournisse un
HAL ? Dans ce cas, quel est le niveau d'abstraction ? Qui définit quelles
opérations offre cette couche ?
Ou au contraire le HAL est-il intimement lié au matériel, dans ce cas
quelle est la différence avec un driver qui expose une interface à peu près
standard à l'OS (comme NDIS par exemple) ?
Le HAL est pratiquement entièrement écrit en assembleur du processeur sur lequel NT/2000/2003/XP fonctionne.
Juste pour être sûr, ma citation concernait spécifiquement les drivers vidéo d'XFree - j'avoue que cette partie du fil a un peu dégénéré en HS.
Il permet simplement a des programmeurs de développer leur driver en C ou autre langage (C# ou même VB :-) )
J'aimerais bien voir ça, tiens, un driver en C# ou VB :-)
Cela dit c'est vrai, à partir du moment où l'interface exposée par HAL peut être importée en VB c'est plus ou moins possible de l'utiliser.
Sauf que...
1. Les types ne sont pas directement compatibles, il faudra donc écrire des fonctions pour effectuer le transtypage proprement. 2. Dans le cas d'un driver, il faut que celui-ci expose une interface qui va bien pour le système, ce qui est AMHA non trivial à faire en VB. 3. Du PCode en ring0, ou tout simplement dans l'espace Kernel ???
Une question me vient, vous saurez peut-être y répondre :
Si je fournis ma propre couche HAL qui émule du matériel, serai-je capable de faire tourner Windows ? Si c'est le cas, pourquoi le projet XenoXP a-t-il été obligé d'accéder au code source et pourquoi a-t-il fallu créer une version personnalisée ?
Sinon je reformule ma question originelle : HAL fait-il une abstraction abstraction au niveau des concepts (bus, horloge...), des technologies (obio, pci, sbus...) ou des composants (VIA, AT&T...) ou autre ?
-- Cyrille Szymanski
"GG" <news@nospam.assysm.com> wrote in news:42aa055b$0$6110
$636a15ce@news.free.fr:
Bonjour,
Il me semble que ces pilotes sont écrits en C
Le HAL est pratiquement entièrement écrit en assembleur
du processeur sur lequel NT/2000/2003/XP fonctionne.
Juste pour être sûr, ma citation concernait spécifiquement les drivers
vidéo d'XFree - j'avoue que cette partie du fil a un peu dégénéré en HS.
Il permet simplement a des programmeurs de développer
leur driver en C ou autre langage (C# ou même VB :-) )
J'aimerais bien voir ça, tiens, un driver en C# ou VB :-)
Cela dit c'est vrai, à partir du moment où l'interface exposée par HAL
peut être importée en VB c'est plus ou moins possible de l'utiliser.
Sauf que...
1. Les types ne sont pas directement compatibles, il faudra donc écrire
des fonctions pour effectuer le transtypage proprement.
2. Dans le cas d'un driver, il faut que celui-ci expose une interface qui
va bien pour le système, ce qui est AMHA non trivial à faire en VB.
3. Du PCode en ring0, ou tout simplement dans l'espace Kernel ???
Une question me vient, vous saurez peut-être y répondre :
Si je fournis ma propre couche HAL qui émule du matériel, serai-je
capable de faire tourner Windows ? Si c'est le cas, pourquoi le projet
XenoXP a-t-il été obligé d'accéder au code source et pourquoi a-t-il
fallu créer une version personnalisée ?
Sinon je reformule ma question originelle : HAL fait-il une abstraction
abstraction au niveau des concepts (bus, horloge...), des technologies
(obio, pci, sbus...) ou des composants (VIA, AT&T...) ou autre ?
Le HAL est pratiquement entièrement écrit en assembleur du processeur sur lequel NT/2000/2003/XP fonctionne.
Juste pour être sûr, ma citation concernait spécifiquement les drivers vidéo d'XFree - j'avoue que cette partie du fil a un peu dégénéré en HS.
Il permet simplement a des programmeurs de développer leur driver en C ou autre langage (C# ou même VB :-) )
J'aimerais bien voir ça, tiens, un driver en C# ou VB :-)
Cela dit c'est vrai, à partir du moment où l'interface exposée par HAL peut être importée en VB c'est plus ou moins possible de l'utiliser.
Sauf que...
1. Les types ne sont pas directement compatibles, il faudra donc écrire des fonctions pour effectuer le transtypage proprement. 2. Dans le cas d'un driver, il faut que celui-ci expose une interface qui va bien pour le système, ce qui est AMHA non trivial à faire en VB. 3. Du PCode en ring0, ou tout simplement dans l'espace Kernel ???
Une question me vient, vous saurez peut-être y répondre :
Si je fournis ma propre couche HAL qui émule du matériel, serai-je capable de faire tourner Windows ? Si c'est le cas, pourquoi le projet XenoXP a-t-il été obligé d'accéder au code source et pourquoi a-t-il fallu créer une version personnalisée ?
Sinon je reformule ma question originelle : HAL fait-il une abstraction abstraction au niveau des concepts (bus, horloge...), des technologies (obio, pci, sbus...) ou des composants (VIA, AT&T...) ou autre ?
-- Cyrille Szymanski
GG
> Si je fournis ma propre couche HAL qui émule du matériel, serai-je capable de faire tourner Windows ?
Oui IBM l'a fait les processeur PPC, Digital avec les processeurs Alpha et d'autres avec d'autres processeurs.
Sinon je reformule ma question originelle : HAL fait-il une abstraction abstraction au niveau des concepts (bus, horloge...), des technologies (obio, pci, sbus...) ou des composants (VIA, AT&T...) ou autre
Il offre une série d'API pour utiliser les ressources matérielles sans avoir besoin d'aller les configurer nous même en langage machine.
> Si je fournis ma propre couche HAL qui émule du matériel, serai-je
capable de faire tourner Windows ?
Oui IBM l'a fait les processeur PPC, Digital avec les processeurs Alpha
et d'autres avec d'autres processeurs.
Sinon je reformule ma question originelle : HAL fait-il une abstraction
abstraction au niveau des concepts (bus, horloge...), des technologies
(obio, pci, sbus...) ou des composants (VIA, AT&T...) ou autre
Il offre une série d'API pour utiliser les ressources matérielles sans
avoir besoin d'aller les configurer nous même en langage machine.
> Si je fournis ma propre couche HAL qui émule du matériel, serai-je capable de faire tourner Windows ?
Oui IBM l'a fait les processeur PPC, Digital avec les processeurs Alpha et d'autres avec d'autres processeurs.
Sinon je reformule ma question originelle : HAL fait-il une abstraction abstraction au niveau des concepts (bus, horloge...), des technologies (obio, pci, sbus...) ou des composants (VIA, AT&T...) ou autre
Il offre une série d'API pour utiliser les ressources matérielles sans avoir besoin d'aller les configurer nous même en langage machine.
Si je fournis ma propre couche HAL qui émule du matériel, serai-je capable de faire tourner Windows ?
Oui IBM l'a fait les processeur PPC, Digital avec les processeurs Alpha et d'autres avec d'autres processeurs.
Alors pourquoi XenoXP n'est pas tout simplement une couche HAL ?
Sinon tu fais référence aux versions de NT pour architectures non PC ? N'y avait-il que HAL qui changeait ? Par exemple NT/Mips limitait la taille de la mémoire virtuelle utilisable à 4 Go, cette limitation se situait-elle uniquement au niveau de HAL ?
Sinon je reformule ma question originelle : HAL fait-il une abstraction abstraction au niveau des concepts (bus, horloge...), des technologies (obio, pci, sbus...) ou des composants (VIA, AT&T...) ou autre
Il offre une série d'API pour utiliser les ressources matérielles sans avoir besoin d'aller les configurer nous même en langage machine.
Les ressources matérielles manipulées sont elles appelées BUS, Horloge etc. ou plus spécifiquement bus PCI, SBus ? J'ai trouvé des arguments pour les deux visions.
-- Cyrille Szymanski
"GG" <news@nospam.assysm.com> wrote in
news:42ac0c16$0$4923$636a15ce@news.free.fr:
Salut,
Si je fournis ma propre couche HAL qui émule du matériel, serai-je
capable de faire tourner Windows ?
Oui IBM l'a fait les processeur PPC, Digital avec les processeurs
Alpha et d'autres avec d'autres processeurs.
Alors pourquoi XenoXP n'est pas tout simplement une couche HAL ?
Sinon tu fais référence aux versions de NT pour architectures non PC ?
N'y avait-il que HAL qui changeait ? Par exemple NT/Mips limitait la
taille de la mémoire virtuelle utilisable à 4 Go, cette limitation se
situait-elle uniquement au niveau de HAL ?
Sinon je reformule ma question originelle : HAL fait-il une
abstraction abstraction au niveau des concepts (bus, horloge...), des
technologies (obio, pci, sbus...) ou des composants (VIA, AT&T...) ou
autre
Il offre une série d'API pour utiliser les ressources matérielles sans
avoir besoin d'aller les configurer nous même en langage machine.
Les ressources matérielles manipulées sont elles appelées BUS, Horloge
etc. ou plus spécifiquement bus PCI, SBus ? J'ai trouvé des arguments
pour les deux visions.
Si je fournis ma propre couche HAL qui émule du matériel, serai-je capable de faire tourner Windows ?
Oui IBM l'a fait les processeur PPC, Digital avec les processeurs Alpha et d'autres avec d'autres processeurs.
Alors pourquoi XenoXP n'est pas tout simplement une couche HAL ?
Sinon tu fais référence aux versions de NT pour architectures non PC ? N'y avait-il que HAL qui changeait ? Par exemple NT/Mips limitait la taille de la mémoire virtuelle utilisable à 4 Go, cette limitation se situait-elle uniquement au niveau de HAL ?
Sinon je reformule ma question originelle : HAL fait-il une abstraction abstraction au niveau des concepts (bus, horloge...), des technologies (obio, pci, sbus...) ou des composants (VIA, AT&T...) ou autre
Il offre une série d'API pour utiliser les ressources matérielles sans avoir besoin d'aller les configurer nous même en langage machine.
Les ressources matérielles manipulées sont elles appelées BUS, Horloge etc. ou plus spécifiquement bus PCI, SBus ? J'ai trouvé des arguments pour les deux visions.
-- Cyrille Szymanski
Gilles Vollant
a écrit dans le message de news:
Ahem... La HAL fait partie de l'architecture de NT depuis la version 3.51, soit bien avant 97/98. A l'origine, la HAL a été écrite pour pouvoir supporter les différentes architectures x86, Alpha, etc... avec le même kernel NT écrit en C. -----
Même plus, je me souvient que lors que la présentation de la béta de NT 3.1 (1992), on parlait déjà de la HAL comme étant au coeur du système, "sous" les pilote de périphérique.
Je crois que le code qui gère l'allocation de temps processeurs au différent thread (en tout cas qui execute les interruptions pour passer d'un thread à l'autre) est dans la hal
<adebaene@club-internet.fr> a écrit dans le message de news:
1118224945.436182.189450@g44g2000cwa.googlegroups.com...
Ahem... La HAL fait partie de l'architecture de NT depuis la version
3.51, soit bien avant 97/98. A l'origine, la HAL a été écrite pour
pouvoir supporter les différentes architectures x86, Alpha, etc...
avec le même kernel NT écrit en C.
-----
Même plus, je me souvient que lors que la présentation de la béta de NT 3.1
(1992), on parlait déjà de la HAL comme étant au coeur du système, "sous"
les pilote de périphérique.
Je crois que le code qui gère l'allocation de temps processeurs au différent
thread (en tout cas qui execute les interruptions pour passer d'un thread à
l'autre) est dans la hal
Ahem... La HAL fait partie de l'architecture de NT depuis la version 3.51, soit bien avant 97/98. A l'origine, la HAL a été écrite pour pouvoir supporter les différentes architectures x86, Alpha, etc... avec le même kernel NT écrit en C. -----
Même plus, je me souvient que lors que la présentation de la béta de NT 3.1 (1992), on parlait déjà de la HAL comme étant au coeur du système, "sous" les pilote de périphérique.
Je crois que le code qui gère l'allocation de temps processeurs au différent thread (en tout cas qui execute les interruptions pour passer d'un thread à l'autre) est dans la hal
Gilles Vollant
"Jean-Claude BELLAMY" a écrit dans le message de news: 42a6c791$0$11696$
Je rappelle qu'à ses débuts Windows NT (version 3.1) existait pour les 4 plates-formes suivantes : - Intel i386 - DEC Alpha - MIPS - PowerPC
Windows 2003 server est toujours autant multiplateforme : - 32 bits, alias Intel i386 (même si depuis NT4, un 486 est néccessaire pour booter) - 64 bits pour AMD64 / Intel EM64T - 64 bits Itanium
Même si on a eu un passage avec à une époque Windows 2000 disponible uniquement en 32 bits "i386" (mais avec un Windows 2000 64 bits pour Dec Alpha qui poursuivait sa carrière clandestine dans les labos MS, en attendant de passer le relais à l'Itanium), le concept de portabilité continue :-)
Enfin, je crois que le noyau NT (avant que l'interface arrive) a été aussi codé sur un vieux processeur RISC Intel (i860 je crois, mais à vérifier), quand MS voulait vérifier que le noyau NT était portable, et avant d'avoir les Mips et Alpha sous la main.
On change un peu de sujet, mais j'aime bien cet aspect "portable" de nt
"Jean-Claude BELLAMY" <Jean-Claude.Bellamy@wanadoo.fr> a écrit dans le
message de news: 42a6c791$0$11696$8fcfb975@news.wanadoo.fr...
Je rappelle qu'à ses débuts Windows NT (version 3.1) existait pour les 4
plates-formes suivantes :
- Intel i386
- DEC Alpha
- MIPS
- PowerPC
Windows 2003 server est toujours autant multiplateforme :
- 32 bits, alias Intel i386 (même si depuis NT4, un 486 est néccessaire pour
booter)
- 64 bits pour AMD64 / Intel EM64T
- 64 bits Itanium
Même si on a eu un passage avec à une époque Windows 2000 disponible
uniquement en 32 bits "i386" (mais avec un Windows 2000 64 bits pour Dec
Alpha qui poursuivait sa carrière clandestine dans les labos MS, en
attendant de passer le relais à l'Itanium), le concept de portabilité
continue :-)
Enfin, je crois que le noyau NT (avant que l'interface arrive) a été aussi
codé sur un vieux processeur RISC Intel (i860 je crois, mais à vérifier),
quand MS voulait vérifier que le noyau NT était portable, et avant d'avoir
les Mips et Alpha sous la main.
On change un peu de sujet, mais j'aime bien cet aspect "portable" de nt
"Jean-Claude BELLAMY" a écrit dans le message de news: 42a6c791$0$11696$
Je rappelle qu'à ses débuts Windows NT (version 3.1) existait pour les 4 plates-formes suivantes : - Intel i386 - DEC Alpha - MIPS - PowerPC
Windows 2003 server est toujours autant multiplateforme : - 32 bits, alias Intel i386 (même si depuis NT4, un 486 est néccessaire pour booter) - 64 bits pour AMD64 / Intel EM64T - 64 bits Itanium
Même si on a eu un passage avec à une époque Windows 2000 disponible uniquement en 32 bits "i386" (mais avec un Windows 2000 64 bits pour Dec Alpha qui poursuivait sa carrière clandestine dans les labos MS, en attendant de passer le relais à l'Itanium), le concept de portabilité continue :-)
Enfin, je crois que le noyau NT (avant que l'interface arrive) a été aussi codé sur un vieux processeur RISC Intel (i860 je crois, mais à vérifier), quand MS voulait vérifier que le noyau NT était portable, et avant d'avoir les Mips et Alpha sous la main.
On change un peu de sujet, mais j'aime bien cet aspect "portable" de nt
Gilles Vollant
"Jean-Claude BELLAMY" a écrit dans le message de news: 42a6c791$0$11696$
Pour une architecture de processeur donnée (Intel et compatibles , DEC Alpha, MIPS et Power PC), le fait d'avoir cette couche HAL permettait d'utiliser les MEMES binaires pour le noyau et les pîlotes de périphériques. HAL gère :
Soyons plus précis : les mêmes binaires pour toutes les machines du même processeurs (mais on avait les binaires i386 d'un côté, Mips de l'autre, etc..).
Du temps où il y avait plusieurs HAL disponibles (-> NT4), le choix se faisait à l'installation de NT. - soit on retenait celui détecté automatiquement, - soit on en choisissait un dans la liste affichée par l'installation :
XP (et même 2003 server) 32 bits ont toujours plusieurs HAL. Il y a notamment une HAL differente suivants que l'on est ou pas multiprocesseur, et que la machine et son Bios supporte l'ACPI ou non pour l'allocation de ressource (IRQ...)
XP/2003 64 bits pour AMD64/ Intel EM64T ne contient qu'une seule HAL (ACPI uniquement, mono ou multiprocesseur unifiée)
tout cela pour dire qu'il y a une grande continuité entre NT3.1 et 2003 server pour l'architecture et ce qu'elle permet
"Jean-Claude BELLAMY" <Jean-Claude.Bellamy@wanadoo.fr> a écrit dans le
message de news: 42a6c791$0$11696$8fcfb975@news.wanadoo.fr...
Pour une architecture de processeur donnée (Intel et compatibles , DEC
Alpha, MIPS et Power PC), le fait d'avoir cette couche HAL permettait
d'utiliser les MEMES binaires pour le noyau et les pîlotes de
périphériques.
HAL gère :
Soyons plus précis : les mêmes binaires pour toutes les machines du même
processeurs (mais on avait les binaires i386 d'un côté, Mips de l'autre,
etc..).
Du temps où il y avait plusieurs HAL disponibles (-> NT4), le choix se
faisait à l'installation de NT.
- soit on retenait celui détecté automatiquement,
- soit on en choisissait un dans la liste affichée par l'installation :
XP (et même 2003 server) 32 bits ont toujours plusieurs HAL. Il y a
notamment une HAL differente suivants que l'on est ou pas multiprocesseur,
et que la machine et son Bios supporte l'ACPI ou non pour l'allocation de
ressource (IRQ...)
XP/2003 64 bits pour AMD64/ Intel EM64T ne contient qu'une seule HAL (ACPI
uniquement, mono ou multiprocesseur unifiée)
tout cela pour dire qu'il y a une grande continuité entre NT3.1 et 2003
server pour l'architecture et ce qu'elle permet
"Jean-Claude BELLAMY" a écrit dans le message de news: 42a6c791$0$11696$
Pour une architecture de processeur donnée (Intel et compatibles , DEC Alpha, MIPS et Power PC), le fait d'avoir cette couche HAL permettait d'utiliser les MEMES binaires pour le noyau et les pîlotes de périphériques. HAL gère :
Soyons plus précis : les mêmes binaires pour toutes les machines du même processeurs (mais on avait les binaires i386 d'un côté, Mips de l'autre, etc..).
Du temps où il y avait plusieurs HAL disponibles (-> NT4), le choix se faisait à l'installation de NT. - soit on retenait celui détecté automatiquement, - soit on en choisissait un dans la liste affichée par l'installation :
XP (et même 2003 server) 32 bits ont toujours plusieurs HAL. Il y a notamment une HAL differente suivants que l'on est ou pas multiprocesseur, et que la machine et son Bios supporte l'ACPI ou non pour l'allocation de ressource (IRQ...)
XP/2003 64 bits pour AMD64/ Intel EM64T ne contient qu'une seule HAL (ACPI uniquement, mono ou multiprocesseur unifiée)
tout cela pour dire qu'il y a une grande continuité entre NT3.1 et 2003 server pour l'architecture et ce qu'elle permet
Gilles Vollant
"AMcD®" a écrit dans le message de news: 42a73671$0$8112$
Cyrille Szymanski wrote:
Pourquoi cela n'a-t-il pas abouti ?
Parce que Kro ne vendait pas franchement beaucoup d'OS sous ALPHA et consort. Ils ont donc arrêté.
d'après http://www.windowsitpro.com/Article/ArticleID/19345/19345.html?Ad=1 c'est aussi Compaq qui a pris la decision d'arreter, quelques semaines avant la sortie de Windows 2000 qui était pret pour alpha
"AMcD®" <arnold.mcdonald@free.fr> a écrit dans le message de news:
42a73671$0$8112$626a14ce@news.free.fr...
Cyrille Szymanski wrote:
Pourquoi cela n'a-t-il pas abouti ?
Parce que Kro ne vendait pas franchement beaucoup d'OS sous ALPHA et
consort. Ils ont donc arrêté.
d'après http://www.windowsitpro.com/Article/ArticleID/19345/19345.html?Ad=1
c'est aussi Compaq qui a pris la decision d'arreter, quelques semaines avant
la sortie de Windows 2000 qui était pret pour alpha
"AMcD®" a écrit dans le message de news: 42a73671$0$8112$
Cyrille Szymanski wrote:
Pourquoi cela n'a-t-il pas abouti ?
Parce que Kro ne vendait pas franchement beaucoup d'OS sous ALPHA et consort. Ils ont donc arrêté.
d'après http://www.windowsitpro.com/Article/ArticleID/19345/19345.html?Ad=1 c'est aussi Compaq qui a pris la decision d'arreter, quelques semaines avant la sortie de Windows 2000 qui était pret pour alpha
Gilles Vollant
"Jean-Claude BELLAMY" a écrit dans le message de news: 42a76d7d$0$3304$
Actuellement, Dave CUTLER est (était?) toujours chez Microsoft, en tant que responsable du programme 64 bits http://www.microsoft.com/presspass/features/2000/jul00/07-03engineers2.mspx
Il n'est pas completement nul, je crois
"Jean-Claude BELLAMY" <Jean-Claude.Bellamy@wanadoo.fr> a écrit dans le
message de news: 42a76d7d$0$3304$8fcfb975@news.wanadoo.fr...
Actuellement, Dave CUTLER est (était?) toujours chez Microsoft, en tant
que responsable du programme 64 bits
http://www.microsoft.com/presspass/features/2000/jul00/07-03engineers2.mspx
"Jean-Claude BELLAMY" a écrit dans le message de news: 42a76d7d$0$3304$
Actuellement, Dave CUTLER est (était?) toujours chez Microsoft, en tant que responsable du programme 64 bits http://www.microsoft.com/presspass/features/2000/jul00/07-03engineers2.mspx
Il n'est pas completement nul, je crois
Thierry
Bonjour,
Gilles Vollant a écrit :
Je crois que le code qui gère l'allocation de temps processeurs au différent thread (en tout cas qui execute les interruptions pour passer d'un thread à l'autre) est dans la hal
Ca serait logique puisque la gestion des processus/thread differe suivant qu'on est sur une archi mono ou multi processeur.
-- « Le travail est probablement ce qu'il y a sur cette terre de plus bas et de plus ignoble. Il n'est pas possible de regarder un travailleur sans maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager, dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. » Boris VIAN
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
Bonjour,
Gilles Vollant a écrit :
Je crois que le code qui gère l'allocation de temps processeurs au
différent thread (en tout cas qui execute les interruptions pour
passer d'un thread à l'autre) est dans la hal
Ca serait logique puisque la gestion des processus/thread differe suivant
qu'on est sur une archi mono ou multi processeur.
--
« Le travail est probablement ce qu'il y a sur cette terre de plus bas et
de plus ignoble. Il n'est pas possible de regarder un travailleur sans
maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager,
dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. »
Boris VIAN
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
Je crois que le code qui gère l'allocation de temps processeurs au différent thread (en tout cas qui execute les interruptions pour passer d'un thread à l'autre) est dans la hal
Ca serait logique puisque la gestion des processus/thread differe suivant qu'on est sur une archi mono ou multi processeur.
-- « Le travail est probablement ce qu'il y a sur cette terre de plus bas et de plus ignoble. Il n'est pas possible de regarder un travailleur sans maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager, dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. » Boris VIAN
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
