2010-04-02 61 views
1

Existe-t-il une alternative à l'extension __attribute__ spécifique non-ISO gcc sur les noyaux 64 bits?Quelles alternatives à __attribute__ existent sur les noyaux 64 bits?

Trois types que j'ai remarqué sont: les attributs de fonction, les attributs de type et les attributs de variable.

par ex. Je voudrais éviter d'utiliser __attribute__((__packed__)) pour les structures passées sur le réseau, même si un code basé sur gcc l'utilise.

Des suggestions ou des pointeurs sur la façon d'éviter entièrement__attribute__ utilisation dans les systèmes C/code noyau?

merci Saifi.

+0

Pourquoi voudriez-vous faire cela? attribut ((emballé)) a été mis dans le code de réseautage pour de très bonnes raisons ... –

+0

Bonjour Sam: Je risquerais d'éviter complètement les codes dans le code! Vous avez des suggestions? merci Saifi. –

+0

Bon, je comprends ... quels compilateurs, plates-formes et matériels voulez-vous supporter? –

Répondre

1

Toutes les suggestions ou conseils sur la façon de tout éviter attribut utilisation dans les systèmes C/code du noyau?

Vous pouvez construire vos paquets réseau pièce par pièce, en copiant chaque élément de données au bon endroit dans un tampon char*.

Avantages: vous n'avez pas des problèmes d'alignement et il est généralement portable, surtout si vous utilisez les types entiers exacte largeur de <stdint.h>

Inconvénients: il est fastidieux et potentiellement sujettes à erreur

+0

Salut James: Merci pour votre réponse.Je souhaite éviter tous les attributs gcc - Function, Variable et Type. S'il vous plaît voir http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Function-Attributes.html http://gcc.gnu.org/onlinedocs/gcc-4.0.0/ gcc/Variable-Attributes.html http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Type-Attributes.html par ex. __attribute__ ((__transparent_union__)); Je suis sûr que toutes ces extensions gcc ne sont pas portables à travers les différents compilateurs C et ce qui est jeté dans une commodité plus tard vient hanter comme «vendeur-lockin». Mon point de mire est le code C/noyau conforme à la norme ISO. –

+0

@Saifi: Si vous ne voulez pas utiliser les attributs d'habillage de structure spécifiques à l'implémentation, vous devez faire ce que je décris dans ma réponse ou une variante de celle-ci: copier chaque membre de structure dans un tampon de caractères. –

+0

@Safi: le "lock-in vendeur" n'est pas un gros problème si vous êtes prudent. Tous les compilateurs sérieux fourniront quelques moyens d'obtenir la mise en page que vous voulez, ce n'est tout simplement pas standard. Le pire des cas est donc que vous devez redéfinir toutes vos structures pour le nouveau compilateur. Une grande pile de 'asserts' dans votre suite de tests basée sur' sizeof' et 'offsetof 'vous permettra de détecter les problèmes avant qu'ils ne mordent. Appelez-le code "facilement portable", par opposition au vrai code portable. –

0

I » Je suppose en fonction de vos commentaires que c'est votre code que vous voulez changer, pas tout le noyau Linux (etc).

Je ne suis pas sûr de la fonction attributs etc mais spécifiquement pour l'attribut packed, j'ai fait ce qui suit sans aucun problème jusqu'à présent. Fondamentalement, au lieu de compter sur le compilateur à emballer, vous pouvez utiliser des champs de pavés manuels couplés à des assertions à la compilation.

struct foo { 
    u32 field1; 
    u16 field2; 
    u16 pad; // manual padding 
    // continue for other fields that the compiler would automatically pad for you with attribute packed 
    u32 field3; 
}; 

Pour vérifier votre structure, vous pouvez utiliser un assert temps de compilation, quelque chose comme ceci:

#define CASSERT(cond, name) typedef cassert__##name[cond ? 1 : -1] 

CASSERT(offsetof(foo, field1) == 0, field1_wrong); 
CASSERT(offsetof(foo, field2) == 4, field2_wrong); 

Lorsque vos affirmations sont fausses, la construction échouera avec une erreur utile et le numéro de ligne