Journal openspec c'est possible ???

Posté par  (site Web personnel) .
Étiquettes : aucune
0
9
août
2006
Un idée me viens en tête, je ne dois certainement pas être le premier à l'avoir, mais je l'expose :
Pour tous les développeurs de kernels libres : linux, variantes BSD, reactos, ... Il y a un problème majeur, la reconnaissance du matériel et surtout du matériel récent par des driver libres.
Pour pouvoir développer ces drivers, ils veulent les specs du matos.

De plus, il est courant de voir des drivers sur disponibles sur certains OS, ne pas être disponibles sur d'autres, la portage n'est pas facile : architecture logicielle différentes, etc. Par exemple les moults driver linux non présent sur OpenBSD ou le driver pour le dernier chipset wifi d'Intel complètement libre et propre sous OpenBSD ce qui n'est pas le cas sous Linux.

La plupart du temps quand un développeur fait un driver, vue qu'il n'a pas les specs, il fait du reverse engineering sur le matériel pour connaître son fonctionnement et pouvoir s'interfacer avec. Il découvre donc les specs au fur et à mesure. Si un dev linux le fait pour le driver Linux, il est certain qu'un dev OpenBSD le refera aussi, pour NetBSD etc. pourquoi ne pas centralisé cet effort

Au final beaucoup de ressources gaspillées à refaire le même travail. Ne serait il pas intéressant de créer un site sur le modèle de wikipedia pour centraliser les specs du matériels, de manière légal, que ce soit les specs découvertes, mais aussi les specs officielles des constructeurs quand ceux-ci sont assez ouverts pour les fournir.

Ainsi les développeurs quelques soit l'OS sur lequel ils développent rempliraient/compléteraient cette base d'information et pourrait ainsi collaborer entre eux sur cette partie là.

Tout le monde y gagnerait non ?

Un peu sur le même principe que : http://wiki.multimedia.cx/index.php?title=Main_Page pour les formats multimédias
Qu'est ce que vous en pensez ? réalisable ? intéressant (des devs kernel dans la salle ?) légal (peut être pas dans tous les pays) de mettre à dispo des specs découvertes" ?
  • # Bonne idée !

    Posté par  . Évalué à 1.

    C'est une très bonne idée. Celà dit il faut espérer que suffisament de développeurs libres y adhèrent.
    • [^] # Re: Bonne idée !

      Posté par  (site Web personnel) . Évalué à 6.

      J'avoue que l'aspect légalité me laisse songeur. Je ne pourrais pas dire pourquoi mais vu la tendance générale à protéger les entreprises, j'ai peur qu'une telle initiative soit vite attaquée pour violation de secrets industriels.

      Maintenant, si c'est pris en charge par la FSF et que c'est basé dans un pays sympa, pourquoi pas...
      • [^] # Re: Bonne idée !

        Posté par  . Évalué à 2.

        Si l'on procéde comme avec les drivers broadcom. En 2 phases bien séparées (pour éviter le plagiat):

        1) Une équipe pour le reverse qui documente les spécifications.
        2) Une deuxième qui code le driver à partir des specifications produites par la première équipe.

        Donc, ce type de site regrouperais les efforts des équipes de reverse (1). On pourrait rester sur de l'intéropérabilité pour le (1) ?. Donc pas de problème au niveau légalité ?



        Pour les drivers broadcom le
        (1) http://bcm-specs.sipsolutions.net/
        (2) http://bcm43xx.berlios.de/

        cf wikipedia, technique de la muraille de chine http://en.wikipedia.org/wiki/Chinese_wall#Computer_science (anglais)
    • [^] # Re: Bonne idée !

      Posté par  (site Web personnel) . Évalué à 7.

      cela pourrait tout à fait être une extension du site http://www.vendorwatch.org/index.php?title=Main_Page qui recense les fabricants (vendor) sympathiques ou pas.

      Pour ceux qui sont sympathiques, cela ne coûte rien d'ajouter un lien vers les specs existantes.
      Pour ceux qui ne sont pas sympathiques, cela peut permettre de montrer que le boulot se fait (difficilement) sans eux ou pas...

      Et ça tombe bien, c'est un wiki...
      On en avait déjà parlé sur https://linuxfr.org/2006/05/11/20800.html
      Autant ne pas refaire une nième initiative séparer et plutôt contribuer à l'existant, non ?
      • [^] # Re: Bonne idée !

        Posté par  (site Web personnel) . Évalué à 3.

        Oui autant utiliser leur site si ils le veulent bien. reste le problème de la légalité de publier des specs obtenues par reverse engineering
        • [^] # Re: Bonne idée !

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

          dans un premier temps déjà recenser les liens vers specs des constructeurs coopératifs ça va faire du boulot

          il sera ensuite temps de regarder l'état des specs disponibles pour les constructeurs récalcitrants... par exemple : http://prism54.org/
  • # Use the source luke

    Posté par  (site Web personnel) . Évalué à 3.

    Je ne suis pas un developpeur de drivers mais voila comment je vois les choses.

    Les kernel hacker (Linux ou BSD) developpent leurs drivers. Je ne pense pas que ca les amuseraient de rediger les specs qu'ils ont eu tant de mal a retrouver par reverse enginering.

    Ensuite, si un driver existe sous Linux mais pas pour BSD, un kernel hacker BSD, peut tres bien lire le code Linux en GPL pour en refaire un en BSD. C'est arrivé encore recement pour un driver wifi si je me souviens bien.

    Pour l'inverse, un code BSD peut etre inclus dans un code GPL, donc c'est encore plus simple.
    • [^] # Re: Use the source luke

      Posté par  (site Web personnel) . Évalué à 3.

      Et je dirais même plus, pour échanger, les E-mails, c'est bon, mangez-en. Un dev voulant écrire un driver déjà existant autre part, peut contacter lesauteur de cet autre driver.
      • [^] # Re: Use the source luke

        Posté par  (site Web personnel) . Évalué à 5.

        Oui mais la difficulté est à mon avis plus importante que partir de specs, car legalement un hacker BSD ne peut le faire que si il lit le code du driver GPL pour se faire une idée de comment le matos fonctionne => faire des specs, puis il doit "l'oublier" pour coder en fonction des specs obtenues donc on gagne une étape.
        Mais là je suis d'accord que le hacker linux n'aura pas envie de se faire chier a faire des specs qui ne lui resserviront pas.
        En revanche, les architectures kernel sont très différentes entre les différents OS libre, par exemple (je n'y connais rien en hack kernel c'est ce que j'ai cru comprendre, merci de me corriger si j'ai tord :)) les hackers linux sont assez libres pour le devs de drivers réseaux et l'architecture de leur driver, sous les BSD, ce n'est pas la cas, tous les drivers en tout cas sous OpenBSD reprennent la même architecture, imposée par le kernel pour facilité la maintenance et le développement. Cette architecture n'est pas forcément compatible avec celle de linux donc un hacker linux aura certainement beaucoup de difficulté à rééutiliser un driver BSD, d'ailleur il n'y a pas à ma connaissance beaucoup de repompe de code BSD sous linux ces derniers temps en ce qui concerne les drivers.

        De plus, par reverse engineering un hacker arrivera a retrouver les specs mais pas toujours de manière complète, elles lui permetteront de faire un driver fonctionnel, mais peut être pas un driver ayant toutes les fonctionnalités offerte par le matos, et un autre hacker d'un autre kernel aura peux être d'autre partie de ces specs, et les complètera, permettant au premier d'enrichir son driver.

        De plus, il y a peut être plein de gens qui savent faire du reverse engineering sur du matériel, et donc pondre des specs sans pour autant savoir (avoir envie de) coder des drivers : apparemment l'équipe des drivers broadcom linux fonctionne séparément (comme dit plus haut) avec des spécificateurs et des codeurs. Ca pourrait pas mal faire avancé les choses, moins de reverse pour les hackers, plus de specs.

        Enfin a long terme ça peut peut être pousser les constructeurs à déposer leurs specs eux-même sur un tel site (je rêve peut être un peu là :)).
    • [^] # Re: Use the source luke

      Posté par  . Évalué à 2.

      > Les kernel hacker (Linux ou BSD) developpent leurs drivers. Je ne pense pas que ca les amuseraient de rediger les specs qu'ils ont eu tant de mal a retrouver par reverse enginering

      Heu... c'est pas justement l'inverse le principe de l'Open Source ? Partager son travail par ce qu'il est pas évident et qu'il peut servir aux autres...
      • [^] # Re: Use the source luke

        Posté par  (site Web personnel) . Évalué à 4.

        Heu... c'est pas justement l'inverse le principe de l'Open Source ? Partager son travail par ce qu'il est pas évident et qu'il peut servir aux autres...

        En developpant un driver et en ouvrant son code, le kernel hacker partage son travail. Mais il n'a pas forcement envie d'ecrire une jolie documentation... D'ailleurs il n'y a pas meilleure documentation qu'un code ! :-)
        • [^] # Re: Use the source luke

          Posté par  . Évalué à 2.

          > Mais il n'a pas forcement envie d'ecrire une jolie documentation

          Oui, c'est vrai et on ne peux pas le blamer (je comprend ce que tu veux dire)
          Mais il peut aussi vouloir le faire. dans ce cas, le projet de notre ami prend tout son sens car aujourd'hui, si j'ai bien compris (ce que voulait dire l'auteur de ce journal), il n'y a pas grand chose pour le faire si ce n'est que de prendre sa plume et de publier ca sur sa page perso.

          > D'ailleurs il n'y a pas meilleure documentation qu'un code

          C'est un point de vue. Ce n'est d'ailleurs pas le miens. Je dirais plus que ca dépend de quel type de code. (Typiquement un driver est plutôt "platefrom dependant" et il y a des chances pour que beaucoup de choses soit à refaire et donc à recomprendre).
          Je partage par exemple la conclusion de la commision européenne qui juge que le code rendu "publique" par Microsoft ne suffie pas et n'est pas un documentation suffisante pour assurer l'interopérabilité. Et ce malgré le fait que le code de Microsoft était très commenté.
        • [^] # Re: Use the source luke

          Posté par  (site Web personnel) . Évalué à 7.

          En même temps, c'est un reproche que l'on peut aux développeurs linux, même si le plus important et on les remercies pour ça c'est de codé des drivers, mais sous FreeBSD par exemple, tous les drivers sont systématiquement accompagnés d'un manpage.

          C'est très pratique pour connaitre le matériel supporté : et comment utiliser le driver : http://www.freebsd.org/cgi/man.cgi?query=axe&apropos=0&a(...) par exemple à partir de là j'ai acheté mon adaptateur usb/ethernet sans me poser de question.

          Des ajouts sont régulièrement fait au niveau compatibilité du matériel : les scanners usb sont un bon exemple, la chaine d'identification du scanner est rajoutée au driver, et le nom du scanner rajouté au manpage :
          http://www.freebsd.org/cgi/man.cgi?query=uscanner&apropo(...)

          Très pratique.
          Ca ne prend pas beaucoup de temps au dev et ça change la vie des utilisateurs.

          De la même manière les interfaces dans le kernel sont documentées pour facilité la vie des développeurs, au sein de manpages, par exemple :
          http://www.freebsd.org/cgi/man.cgi?query=usb&sektion=4&a(...)

          Un peu de documentation ça ne fait de mal (c'est chiant et rébarbatif), mais c'est important.

          Pour revenir au sujet :
          Si le mainteneur du driver vient à changé pour des raisons diverses, le suivant sera bien content de trouver les specs, pour pouvoir améliorer le driver, le dev initial a peut être fait un driver qui marche, mais il n'est pas forcément optimum, et du code cochon n'est pas facile à lire, il peut aussi s'être trompé en implémentant certaines parties des spécifications. Bref le code ne reflète pas forcément correctement, ni proprement les specs.
        • [^] # Re: Use the source luke

          Posté par  . Évalué à 8.

          D'ailleurs il n'y a pas meilleure documentation qu'un code ! :-)

          Tu mérites des baffes, heureusement qu'il y a le smiley...
  • # wikihardware.org

    Posté par  . Évalué à 2.

    Bonjour,

    Avec un ami on avait l'intention de créer un site à la wikipedia, qui avait pour but de mettre en relation utilisateur et développeur.

    A l'époque, en avril, on avait fait des petites réunions, on avait même réservé le nom de domaine wikihardware.org.
    Si ca t'intéresse, je te met un compte rendu de réunion (prise de note), sinon le projet est une bonne idée.

    On voulait conseiller l'achat de matériel bien supporté, mettre des robots qui scanne automatiquement les site des constructeurs et qui remplissent automatiquement des modèles (ordinateur portables, desktop, ...) en python.

    Y a deja le robot pywikipedia pour interargir avec mediawiki.
    Voici le lien pour le compte rendu :
    http://bsheep.org/wiki-hardware.txt

    Si tu veux, on peut te mettre a disposition gracieusement le nom de domaine.
    • [^] # Re: wikihardware.org

      Posté par  . Évalué à 5.

      Dans le même genre j'avais l'idée (mais pas le temps), d'un soft qui ferait lspcidrake, lsusb, lsmod, uname -a et demandait ensuite par élements à l'utilisateur si cela fonctionne "out of the box", en ayant mis les mains dans le cambouis ou pas du tout.

      Le tout ferais un message pour une base de donnée. Le but étant de repérer les config qui marchent toute seul, les éventuels conflit, les périphériques qui changent de puces sans changer de nom, etc...

      "La première sécurité est la liberté"

    • [^] # Re: wikihardware.org

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

      si vous êtes dans la logique de continuer, il y a http://dev.librehwdb.tuxfamily.org (l'aspect libre est ajouté à l'aspect "juste ça marche" pour éjecter les pis-aller à la ndiswrapper par exemple).

      l'idée était plutôt de partir sur une base de données qu'un wiki http://dev.librehwdb.tuxfamily.org/tiki-index.php?page=Doc+D(...)
      et profiter des hwdb-clients des différentes distributions pour "automatiser" le process

      Cela est arrêté pour l'instant, mais les ressources sont librement utilisables : il y aurait http://dev.librehwdb.tuxfamily.org/tiki-directory_browse.php à compléter avec http://wiki.eagle-usb.org/wakka.php?wiki=HwDbExistingResourc(...) (il faut s'inscrire au tiki-wiki pour proposer des ajouts) et oui c'est encore un annuaire du libre (matériel) ;-)
      => cela fait déjà une bonne analyse de l'existant
    • [^] # Re: wikihardware.org

      Posté par  (site Web personnel) . Évalué à 6.

      Merci pour la proposition, je m'en occuperait bien, mais pour plusieurs raisons, je ne pense pas être le mieux placé :
      - Je n'y connais rien (pour le moment ?) en développement de driver.
      - Je n'y connais rien (pour le moment ?) en Hardware et encore moins en spécification harware.
      - Je n'ai pas de site sur lequel l'héberger.
      - Enfin et surtout, j'aimerai bien savoir la légalité de la chose avant de me lancé la dedans.

      En ce qui concerne le fait de ne rien y connaitre en hardware et spec hardware, c'est à mon avis très génant pour ce lancer dans l'aventure, car je pense (peut être à tord) que la présentation et la lisibilité des specs est un point important pour que le projet soit réellement utilisé et utilisable. De plus il faut savoir un minimum de quoi on parle. Il s'agit là d'un réflection de quelqu'un (moi) qui n'a aucune idée de ce que peut être le développement de drivers, j'ai juste des infos vulgarisés sur le domaine, mais certainement beaucoup trop vulgarisé (comprendre plein de non sens, idées reçues), et les éléments majeurs d'un tel projets devraient selon moi auvoir une certaine crédibilité auprès des dev kernel pour les motiver à participer un peu plus.

      Secondo, comme précisé plus haut, il serait peut être intéressant de contacter vendorwatch pour héberger ce projet.

      En revanche ce que je peux faire, c'est aidé si quelqu'un se lance là dedans : essayé de récupérer les specs déjà disponible en ligne pour les centralisées, contacté les développeurs kernel des divers projets d'OS OpenSource : Linux, Hurd, FreeBSD, NetBSD, OpenBSD, DragonFly-BSD, Reactos, et tous les autres que j'oublie là mais que j'aurais vite fait de répertorié à se moment là pour les motiver à contribuer.

      En clair je n'ai pas de pétrole, mais des idées et je pense que c'est un bon point de départ.
      • [^] # Re: wikihardware.org

        Posté par  . Évalué à 3.

        « En revanche ce que je peux faire, c'est aidé si quelqu'un se lance là dedans : essayé de récupérer les specs déjà disponible en ligne pour les centralisées, contacté les développeurs kernel des divers projets d'OS OpenSource : Linux, Hurd, FreeBSD, NetBSD, OpenBSD, DragonFly-BSD, Reactos, et tous les autres que j'oublie là mais que j'aurais vite fait de répertorié à se moment là pour les motiver à contribuer. »

        Et pourquoi ne pas le faire si personne ne se lance là-dedans ? Dans tous les cas, ce serait quelque chose d'utile, et en plus, ça pourrait un peu inciter certaines personnes à justement commencer à faire quelque chose aussi (mais pas moi, parce que j'ai piscine).

        Ton idée est bonne, mais comme la plupart des initiatives pour le LL, il ne faut pas trop attendre quelque chose des autres au départ : ce n'est qu'une fois que le projet aura un minimum de résultats concrets que tu verras arriver de l'aide (« on ne prête qu'aux riches » etc.)
        • [^] # Re: wikihardware.org

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

          Je suis d'accord avec toi, mais comme je le dis avant je ne pense pas être assez qualifié pour avoir des résultats concrets. En revanche, si personne de plus qualifié ne veux pas prendre les rennes, je le ferais, tout du moins j'essairai, mais il me semble important de pouvoir présenter les informartions techniques de manières propres et précise. si je le fait c'est comme si une secrétaire faisait un diagramme UML, il y aura peut être toutes les informations, mais se sera certainement inutilisable par les développeurs car non fait dans les règles de l'art.

          Je ne me défile pas pour le projet, je veux (et c'est pour ça que je le présente) le réaliser, mais dans la mesure de mes compétences. Il est important si on ne veut pas faire un projet mort né de s'entourrer des personnes compétentes. De plus il ne s'agit pas là d'un projet de dev, ou je peux pondre un code pas propre mais qui fonctionne, qui attire des gens, et que j'apprenne au fur et a mesure à codé propre grâce au projet. Là si les informations présentées sont inutilisables, personne ne pourra s'en servir. En revanche si quelqu'un de compétent le fait, je serai à même d'apprendre et à en faire d'autres propres, donc utiles.
          • [^] # Re: wikihardware.org

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

            J'ai envoyé un mail à vendorwatch.org pour voir si ça les intéresse d'étendre les fonctionnalité de leur avec ce projet, j'attend la réponse de leur part, je vous tiens au courrant.

Suivre le flux des commentaires

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