Forum général.général Documentation

Posté par  (site web personnel) .
Étiquettes : aucune
0
24
août
2005

Bonjour,

J'ai déjà fais quelques petit programme système, et quand j'ai besoin d'une information système (exemple : Taille d'un disque dure, ….), je n'ai trouvé différentes solutions :

  • Passer des heures à chercher dans les sources de /usr/include pour voir si quelque chose ressemble à ce que je cherche.
  • Passer des heures avec Google pour avoir une piste, puis retourner au premier point.
  • Rechercher un programme qui devrais utilisé la fonction dont j'ai besoin (ca existe pas toujours).
  • Lire des fichiers se trouvant dans /proc (alors qu'il devrais être possible d'obtenir ces informations grâce à des fonctions tel que ioctl….)

Je me suis dit qu'il doit pourtant exister quelque part une doc qui contient toutes les fonctions que l'on peut utiliser pour interagir avec le noyau (idem pour X,…)

Mais où ?

En anglais, il n'y a pas de problème. Mais un site ou on peut retrouver les fonctions noyau est faire une recherche si on ne sais le nom de la fonction.

Par exemple, le "man" : il faut connaitre le nom de la fonction, et pour ioctl, il ne donne pas toutes les possibilités et à quoi elles servent.

Pourquoi ma question ?

Avant j'était développeur Windows. Je développé en Delphi. Il y avait un fichier d'aide Delphi super bien documenté, décrivant toutes les classe Delphi, les méthodes, ….

Mais aussi un fichier d'aide API Windows en anglais (malgrés l'auteur ce document était super bien fait) où on peut rechercher n'importe quel fonction de l'API Windows (fonction qu'on peut utiliser).

Une description détaillé des paramètres et des fonctions, des différentes constantes disponibles ….

J'espere que cela existe aussi sous Linux, mais que je n'ai pas eu la chance de le découvrire.

Merci

  • # bin c'est vaste

    Posté par  . Évalué à 2.

    Pour les docs un lien vers plusieurs doc specifique.
    http://jungla.dit.upm.es/~jmseyas/linux/kernel/hackers-docs.html(...)

    * Lire des fichiers se trouvant dans /proc (alors qu'il devrais être possible d'obtenir ces informations grâce à des fonctions tel que ioctl....)

    Bon la c'est moins simple, ioctl est une porte bidirectionnel entre le noyaux et un programme appli. Par contre chacun est libre de faire passer ce qu'il veut et comme il veut par la, donc a moins de connaitre en detail le module a qui l'on parle on ne ce sert pas des ioctl.
    Aucune doc ne pourra jamais ressencer toutes les facons de communiquer de tous les modules ecrit un jour pour linux.

    Je me suis dit qu'il doit pourtant exister quelque part une doc qui contient toutes les fonctions que l'on peut utiliser pour interagir avec le noyau (idem pour X,...)
    Pour le noyaux en lui meme il n'est responsable que de peut de chose, allocation memoire principallement le reste est a la charge de divers modules construit avec le noyeaux, les appelles systemes de base sont documentées (->google syscall), pour le reste ca depends de chaque modules.

    La difference avec windows c'est que tu ne dispose pas des sources donc il te faut utiliser les interfaces que l'on te donne et comme tu ne peut pas lire ce qu'elle font on te fournis une descruption, avec linux on te founit les sources pour que tu puisse lire ce qu'elle fait reelement et si ca ne te convient pas tu peut copier/coller le code dans un autre prog et le modifier a ta guise.

    En lecture papier je peut te conseiller les tres bons livres indique sur le premier lien avec une grosse preference personnelle sur les livre alessandro rubini (dont le linux device drivers qui est consultable en ligne ou telechargable en pdf)
    • [^] # Re: bin c'est vaste

      Posté par  . Évalué à 3.

      avec linux on te founit les sources pour que tu puisse lire ce qu'elle fait reelement et si ca ne te convient pas tu peut copier/coller le code dans un autre prog et le modifier a ta guise.

      Il n'y a que moi qui pense que ca n'empêche pas de fournir une API bien documentée ? Parce que, aller voir les sources du noyau, c'est bien lorsque tu développes le noyau. Pour des applis, c'est peut-être pas la meilleure des solutions . D'autant plus que c'est assez chiant de se retaper le code à lire ...

      Sinon, pour répondre a la question initiale, l'interface principale entre le noyau et les programmes utilisateur reste les appels systèmes, gérés par la libc. Est-elle correctement documentée sous GNU/Linux? Je sais pas, peut-être que 'info libc' te donnera des renseignements.
      • [^] # Re: bin c'est vaste

        Posté par  (site web personnel) . Évalué à 2.

        Je suis tout a fait d'accord (d'où le but de ma recherche).

        Je pense même que ça permettrai à certain personne ou entreprise à se mettre à la programmation sous Linux.
      • [^] # Re: bin c'est vaste

        Posté par  . Évalué à 1.

        on est d'accord la dessus, une application n'as pas besoin de savoir comment fonctionne le kernel et surtout pas a faire des ioctl ou des syscall.
        Le noyaux et ces interfaces évolue constamment, on as eut 2 version de la couche usb sur le 2.4 et dans le 2.6.x avec x inferieur a 11 un troisieme et une version 4 devrait etre dans le 2.6.12 (pas eut le temps de verifier).
        Autant dire que le temps d'ecrire une doc elle serait deja largement out-of-date.
        L'API a documenté c'est celle des fonctions de base du C (la libc) et des bibliotheque qui gravite autour comme libthreab ou la pthread et d'autres, mais chacunes des library utilisé contient deja de la documentation.
        Lire dans /proc n'est deja pas portable, d'une version a l'autre du kernel ou du module generant ces infos cela peut changer.
        • [^] # Re: bin c'est vaste

          Posté par  . Évalué à 2.

          Le noyaux et ces interfaces évolue constamment, on as eut 2 version de la couche usb sur le 2.4 et dans le 2.6.x avec x inferieur a 11 un troisieme et une version 4 devrait etre dans le 2.6.12 (pas eut le temps de verifier).
          Autant dire que le temps d'ecrire une doc elle serait deja largement out-of-date.


          C'est là que je ne suis pas d'accord.

          Ou est l'intéret de fournir une interface qui évolue constamment sans assurer un minimum de compatibilité avec l'ancienne?
          Dans ce cas c'est inutile de fournir une interface, et de se baser sur celle-ci, sinjon, le temps d'écrire l'appli qui se base sur cette interface, elle serait deja largement out-of-date.

          Que le noyau évolue, ca ne me gene pas. Que l'interface évolue entre 2 versions majeures de noyau, ca ne me gene pas trop non plus, Par contre si les interfaces bougent constamment dans ubne même version majeure du noyau, il y a un problème.
  • # man

    Posté par  (site web personnel) . Évalué à 2.

    Tu as une commande qui recherche dans les pages man :
    apropos
  • # Pour le C++

    Posté par  (site web personnel) . Évalué à 2.

    Pour le C++, j'ai trouvé une bonne documentation (le genre de truc que je cherche pour le noyau Linux)

    http://www.cplusplus.com/(...)

    Par exemple on tape ifstream dans le champs recherche, et on obtient une bonne documentation de cette classe.
  • # glibc

    Posté par  . Évalué à 2.

    Si tu t'intéresse à la programmation bas niveau (console, daemon, ...), il y a la documentation de la glibc sur http://www.gnu.org/software/libc/manual/html_node/index.html(...)

    C'est en gros de la programmation posix. Le manuel doit faire 1000 pages environ, c'est plutôt bien écrit (en angliche, bien sûr), et assez bien classé.

    Sinon, en français, il y a le livre de Crisptophe Blaess, Programmation Système en C sous Linux. Extrêmement clair, qui distingue très bien d'ou provienne les appels (glibc, posix, bsd, Unix SysV, Unix98, ...), accessible aux débutants qui ne connaissent strictement rien à Unix.

    M'enfin, il y a largement de quoi devenir un kador, rien qu'en lisant le manuel de la glibc. Tu as du remarquer que linux est développé en couches, et les programmeurs sont loins d'être aussi paranoïaques que ceux de la glibc, gcc ou gdb. Alors bon, n'espère pas trop trouver des docs tout en un à la delphi, .net, java, ou l'API comprend 90% des besoins.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.