|
Publicité ' | |||||||||||||||||||||||
|
|
#1 | ||||
|
Invité de passage
![]() Franck Ingénieur développement matériel électronique Inscription : avril 2012 Messages : 1 ![]() |
Bonjour à tous,
Un premier post ici pour moi, aussi quelques mots de présentation. D'ordinaire je ne code pas sur des machines classiques puisque je réalise essentiellement du code bas niveau en robotique sur des OS propriétaires, µitron SH4 par ex. Dernièrement il m'est tombé sous la main un embedded computer Moxa 7112 LX Plus dans lequel je mets du code compilé pour réaliser de conversion de protocole de comm. Dedans c'est un arm-linux, peu de place dispo 8Mo de flash restant pour les applis. L'idée d'utiliser cette micro machine pour faire du vpn est venue dernièrement car openvpn y est déjà installé, comme apache et perl. La question du vpn n'est envisageable que si l'on peut "administrer" un minimum la conf ethernet et vpn de la boite. Après avoir jeté un coup d'oeuil rapide sur le sujet, je prends donc en considération l'existence d'un interpréteur perl déjà compilé sur arm, et décides de faire quelques tests. un perl - v indique : This is perl, v5.8.7 built for arm-linux ! J'ai fais divers tests de CGI/perl qui se passent tous pas mal sauf un qui commence à me rendre plus que songeur, voici le topo : Code :
Citation:
On peut noter que la capture à l'aide de "backticks" de $buffer = `/var/sd/net_iface_info`; n'a rien de particulière et fonctionne parfaitement avec quelque chose du style $buffer = `ps -ef`; par exemple. Mais dans l'appel de `/var/sd/net_iface_info` (un C compilé) la valeur de retour est incomplète ! voici ce que donne le même script lancé depuis la console : Citation:
Sauf si à force de chercher je ne vois plus la forêt, ou l'arbre, il me semble toutefois que le code HTML devrait pouvoir s'afficher correctement. Le plus troublant restant pour moi la longueur du buffer mesurée plus courte lors de l'appel CGI via l'Apache embarqué que lors de l'appel par la console. J'ai testé diverses façon de faire, open(PIPE ... etc.) qx(...) et le résultat est tjrs le même. Le temps de latence en C est négligeable, j'ai même ajouté un beep du buzzer de 100ms pour être sûr de passer par la fin de proc. Une chose est étrange, l'appel en console est plus long que via le passage par CGI de Apache, et le résultat complet dans ce cas. Un guru aurait-il une idée lumineuse sur ce mystère ? Franck |
||||
|
|
00
|
Copyright © 2000-2013 - www.developpez.com