[Kos-dev] diverses questions sur la compilation dans kos

[Thomas Petazzoni]

Salut !

David MENTRE wrote:

> J'essaye de voir comment je pourrais envisager de compiler un début de
> commencement de programme, ce qui suscite quelques questions, en vrac :

Ah, très bien ! ;-)

Je suppose que par "programme", tu veux dire "module".

>  - il n'y a pas de risque à exporter des variables avec EXPORT_VARIABLE
>    (je ne considère pas le problème du mutli-threading pour l'instant) ?

EXPORT_VARIABLE ne doit pas être utilisé. Comme indiqué dans loader/mod.h :

/*
  * Be careful : usage GREATLY disapproved
  */
#define EXPORT_VARIABLE(sym)

Elle n'est utilisée que pour définir une autre macro, appelée 
EXPORT_SPINLOCK, qui comme son nom l'indique permet d'exporter des 
spinlocks. C'est uniquement pour cette raison que EXPORT_VARIABLE a été 
mis en place.

C'est donc utilisé pour exporter quelques spinlocks (très peu), et il ne 
faut l'utiliser que pour ça.

>  - où sont définis les niveaux d'initialisation des modules, à quel
>    niveau mettre le sien ?

Les niveaux d'initialisation sont définis dans loader/mod.h. Il n'y a 
pas de convention particulière pour leur utilisation.

Tu n'as pas besoin de définir le tien, tu dois utiliser un de ceux déjà 
disponibles.

Il faut bien différencer les init levels et les post init levels. Les 
init levels, c'est tout ce qui est éxécuté avant que les interruptions 
ne soient mises en route. Les post init levels, bin, c'est après ;-)

>  - où sont définis les options de compilation de gcc (histoire de
>    pouvoir les inclure si besoin dans la compilation des fichiers de mon
>    module si cas tordus) ?

Dans MkVars. Mais si tu veux les surcharger system-wide chez toi, créé 
un fichier .mkvars qui contient tes variables customisées.

>  - comment est-ce que je fais si je veux compiler de l'assembleur (.S) ?
>    Des options particulières ?

Tu mets un fichier .S dans le répertoire du module, et dans le Makefile, 
dans la variable OBJS, tu mets le nomdufichier.o. Les règles feront le 
boulot ;-)

(Théoriquement).

>  - le code que je compte compiler mélange interfaces exportées et
>    cachées (càd que les interfaces exportées sont disseminées dans
>    plusieurs fichiers). Est-ce que l'organisation toto.c/_toto.c n'est
>    qu'une convention et est-ce qu'on peut l'enfreindre[1] ?

toto/_toto.c peut contenir des fonctions exportées et des fonctions 
internes. Il n'y a pas de règles à ce sujet. La seule règle à ce sujet, 
c'est : que toto/toto.c contient juste les init/cleanup modules et les 
macros EXPORT_SYMBOL(), et que le reste des fichiers du module 
commencent par un _.

>  - si j'ai un sprintf dans mon code, je dois le remplacer par un
>    snprintf ?

Oui. sprintf(), ça pue.

>  - est-ce qu'il y a dans kos des trucs du style strlen, memmove ?

Oui. Cf :

  modules/lib/std/string.h
  modules/lib/std/stdio.h

Voilà ;-)

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni at enix.org
http://thomas.enix.org - Jabber: thomas.petazzoni at jabber.dk
KOS: http://kos.enix.org/ - SOS: http://sos.enix.org
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://the-doors.enix.org/pipermail/kos-dev/attachments/20050115/c562500b/signature.pgp