Discussion :

[nulloz]

Bonjour à tous,

Dans le cadre de mon cours de Système d'exploitation, je dois réaliser une programme capable d'afficher les partitions présentes sur le disque principal.

Pour ce faire, je vais lire les quatre entrées des partitions principales (qui se trouvent juste après le MBR). Je dois ensuite, si je détecte une partition étendue (ce qui est le cas ), aller analyser les entrées des partitions logiques.

D'un point de vue technique, j'ouvre le "fichier" /dev/sda en lecture et le traite comme si c'était un bête fichier sur le disque. Jusque là pas de problème, j'arrive à afficher correctement les quatre entrées des partitions principales mais le problème arrive juste après. J'ai la partition étendue qui commence au 10 000 000ème secteurs, ce qui m'amène au 5 120 000 000ème octets. Ce nombre énorme ne rentre pas dans un simple "unsigned int/unsigned long", qui est utilisé pour dans la fonction "lseek()" pour me déplacer dans mon fichier. Le véritable paramètre de "lseek()" est un "off_t" qui, si je regarde le code de "stdio.h" est un "long" ou un "long long" selon la taille de l'entrée prévue dans la table des descripteurs de fichiers ouverts :

104 #if defined(_LP64) || _FILE_OFFSET_BITS == 32
105 typedef long off_t; <typedef:off_t>
106 #else
107 typedef __longlong_t off_t;

De ce côté là, un "long long" m'aurait grandement plu mais apparemment sur le système 32 bits que j'utilise au laboratoire, ce n'est pas ce cas là.

J'ai bien trouvé l'appel système "llseek" (man) mais les résultats sont erratiques. Vous allez me dire que c'est normal avec une entrée de 32bits dans la table des fichiers ouverts mais quand même

Je procède au téléchargement d'une distribution 64bits en espérant que cela fonctionnement (logiquement) mais je ne comprends pas comment fdisk, tournant sur le système 32bits, arrive lui à lire plus loin que 4Go...il doit y avoir une manière de le faire et j'espère que quelqu'un de ce forum connaisse la réponse J'ai pourtant essayé de regarder le code source de fdisk mais je m'y perds très vite.

Merci de votre aide !

[bizulk]

le type "long long" existe bien sur une plateforme 32 bits Linux/gcc. tu n'as pas besoin d'une architecture 64 bits. Ce type est défini à partir de la norme ANSI C99.
Seulement tu t'imagine que la variable ne sera pas 'lue' en un cycle de processeur.

[nulloz]

Mais comment cela est traité au niveau de la position dans la table des descripteurs de fichiers ouverts qui dans ma mémoire est codé sur 4 octets ?

[bizulk]

Il faut faire le bon appel ;

lseek64
Prototype :

off64_t lseek64(int fd, off64_t offset, int whence);

La routine de bibliothèque lseek64() utilise un type sur 64 bits même si off_t est un type 32 bits. Son prototype (et le type off64_t) n’est disponible que lorsqu’on
compile avec

#define _LARGEFILE64_SOURCE

La fonction lseek64() est disponible depuis la glibc 2.1, et elle est définie comme un alias de llseek().

Bonne chance.

[nulloz]

Ca à l'air de fonctionner Un énorme merci pour cette aide très précieuse !

[nicolas.sitbon]

Il faut faire le bon appel ;


Bonne chance.

C'est typiquement ce qu'il ne faut pas faire, logiquement, il n'y a pas besoin de toucher au code, il suffit de passer à la compilation, les flags renvoyés par la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

getconf LFS_CFLAGS

.
et c'est tout, l'ajustement de type et de fonction se fait automatiquement.

[bizulk]

Mr Sitbon,
Comme tu l'as remarqué il s'agit d'une citation des man pages, je n'ai encouragé aucune méthode d'implémentation mais simplément indiqué qu'il y a avait une fonction prenant en paramètre un entier 64 bits.

Il n'y a pas vraiment de "logique" pour gérer la compilation d'un projet, mais plutôt une cohérence à avoir.
Tu peux très bien écrire un fichier d'entêtes avec des symboles pour influencer la compilation, ça a au moins le mérite d'expliciter leur utilisation.

Je ne connaissais pas bien getconf et cela paraît une méthode intéressante, mais je ne suis pas pour l'utilisation de commandes renvoyant la configuration de la machine hôte dans un makefile, surtout si l'on souhaite faire de la compilation croisée.