PipeMangemente integrated in sourceforge SVN

PipeManagement subproject has been added into lgmenu sourdeforge SVN.

For dowloading this subproject, can be done by sourceforge interface
or importing: svn co [Tienes que estar registrado y conectado para ver este vínculo] PM

Thanks Keltek.

vic1972 escribió:PipeManagement subproject has been added into lgmenu sourdeforge SVN.
For dowloading this subproject, can be done by sourceforge interface or importing: svn co [Tienes que estar registrado y conectado para ver este vínculo] PM [...]

Thanks!

Vic, I am now reviewing/testing it and I might have some proposed changes. Since the SVN does not allow for user changes, how do you want to manage proposed changes? Should I send you them in the form of patches?

Hello
Thanks so much,
I was feeling like been alone in the dark.
I will really appreciate new ideas for improvement.
I will check how users can collaborate in the svn directly,
I guess it is only enought to have a valid source-forge username.

Please provide me with your id; or try to do a checkout, then modify some comments, and try to upload
the changes with your sourceforge id.

vic1972 escribió:[...]I will really appreciate new ideas for improvement.

Al ver el diagrama que has publicado [Tienes que estar registrado y conectado para ver este vínculo], me he acordado de algo que qeria preguntarte: ¿se ha discutido la posibilidad de montar PipeManagement como "padre" o "cliente" de DvdPlayer, de forma análoga como lo hace RootApp?. El diagrama sería algo así

[Tienes que estar registrado y conectado para ver esa imagen]

La invocación se haría sin pipes ni fifos; concretamente: "PipeManagement DvdPlayer" (o bien "Pipemanagement RootApp DvdPlayer".

Esto se puede hacer fácilmente mediante las llamadas: pipe() (2), dup() (2) y execv() (3) (además de fork() (2)). Este montaje es algo más limpio que el que tienes ahora implementado y creo que mejoraría algo la robustez/estabilidad. ¿Qué opinas?

I will check how users can collaborate in the svn directly, I guess it is only enought to have a valid source-forge username. Please provide me with your id; or try to do a checkout, then modify some comments, and try to upload the changes with your sourceforge id.

Gracias. Espera que intente hacer un commit de prueba (aunque creo que para eso hay que tener permisos de dev). Ya te diré algo mañana o pasado.

Saludos,

Que bueno,
lo primero felicitarte por el buen grafico realizado.
Para interesante, nos quitariamos un pipe de comunicacion.
Veo que se quedaria el tail -f del command_sender, quizas tambien se podria quitar ...

Creo que se podria realizar primero una pequeña maqueta con aplicaciones sencillas , tipo hola mundo,
para probar bien todos los mecanismos descritos en el grafico.

vic1972 escribió:Para interesante, nos quitariamos un pipe de comunicacion. Veo que se quedaria el tail -f del command_sender, quizas tambien se podria quitar ...

Como bien dices, el "tail -f ..." ya no haría ninguna falta. Lo he dejado como una entrada más al PM porque creo que es realmente útil como método sencillo de enviar comandos al MS450 por ejemplo desde shell scripts...

Creo que se podria realizar primero una pequeña maqueta con aplicaciones sencillas , tipo hola mundo, para probar bien todos los mecanismos descritos en el grafico.

Aquí va una "maqueta":

Código:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <errno.h>
#include <signal.h>

/*----------------------------------------------------------------------- */
static int  fdin[2], fdout[2];  /* child's ("server") input/output pipes */
static pid_t pid=-1;                                      /* child's PID */

/*----------------------------------------------------------------------- */
void Bye() {
  if(errno) printf("Error %d\n", errno); 
  if(pid > 0) {close(fdout[0]); close(fdin[1]); kill(pid,SIGKILL);}
}
/*----------------------------------------------------------------------- */
/* -- Executes the "server" and connects its stdin/stfout to the pipes -- */
int sysInOutOpen(char *server) {
  pipe(fdin); pipe(fdout);

  if((pid = fork()) != (pid_t)0) return 1;          /* This is the father */
  else if (pid == (pid_t)0) { char *argv[2];        /* This is the child  */
    close(0);  dup(fdin[0]);              /* connects stdin  to the pipe */
    close(1);  dup(fdout[1]);              /* connects stdout to the pipe */
    argv[0] = server ; argv[1] = 0;
    execv(server, argv);                      /* child becomes the server */
    return errno;                /* we can reach here only if execv fails */
  }
  else {pid= -1; return errno;}                            /* fork failed */
}


/*----------------------------------------------------------------------- */
int main(int argc, char *argv[]) {
  const int N=512, M=16384; char line[N]; char buf[M]; int count;
  if(argc!=2) {fprintf(stderr, "\nUse: pipeTest pathBinProg\n\n"); exit(1);}
 
  if(! sysInOutOpen(argv[1])) Bye();                /* we are the father */
  while(1) {
    printf("??? ");                                            /* prompt */
    fgets(line, N, stdin);                          /* father reads line */
    if(! write(fdin[1], line, strlen(line))) Bye(); /* writes it to child */
    if((count=read(fdout[0], buf, M))<0) Bye();  /* reads child's output */
    write(1, buf, count);                        /* prints child's output */
  }
  Bye();
}

Puedes probarlo con cualqueir programa ejecutable que tenga y salida y entrada (de texto). Por ejemplo con bash:

Código:

pipeTest /usr/bin/bash

Ahora tecleas un comando y obtienes la salida: en fin, la tontería del siglo: pero creo que ilustra la idea y cómo hacerlo.

Ya dirás...
Saludos,

Gracias por la maqueta, funciona muy bien.
[victor@victor pipeTest]$ gcc pipeTest.c
[victor@victor pipeTest]$ ls
a.out pipeTest.c
[victor@victor pipeTest]$ ./a.out bash
Server:bash
???
hola
^C
[victor@victor pipeTest]$

Ya estoy pensando en posibles adaptaciones

vic1972 escribió:[...]funciona muy bien. [...]Ya estoy pensando en posibles adaptaciones :)

¡Me alegro! Si quieres ayuda, ya sabes.

Por cierto, como decía [Tienes que estar registrado y conectado para ver este vínculo], creo que PM tiene demasaidas llamadas a "system()". Estas llamadas crean una (indeseable) dependencia explícita de busybox. Idealmente no debería haber ninguna; excepto quizás para alguna tarea muy específica y de uso excepcional como 'system("/usr/local/etc/PipeManagement/scripts/install"' (y tal vez para invocar las "Custom scripts" -- aunque yo esto lo quitaría de PipeManagement y lo haría con otro pequeño programa independiente). Todasl las otras llamadas "system()" se pueden sustituir por llamadas al sistema que no requieren invocar para nada a busybox. Si quieres que me encargue de recodificar todas estas partes de PM, dímelo y me pondré a ello (espero que en un par de semanas o antes).

Saludos,

Hola,
si, entiendo que habria que limitar las llamadas a system.

Pero estas no se realizan continuamente, sino en momentos puntuales.
Por ejemplo: instalar nueva version de PM, ejecutar custom scripts, usuario pida hacer copia de seguridad de fichero canales, etc.


Pero bueno, vale, entiendo que es mejor hacer las cosas de forma "nativa" y no usar busybox porque es un unico fichero
de gran tamaño que carga en memoria, mas los problemas de re-entradas.

Los systems que he detectado son para:
wget
install bash scripts
chmod
custom bash scripts
cp
reboot
ln
touch
grep


Vale, el copy es facil implementar.
Pero lo que tu comentas, es que implementemos ( o copiemos) codigo para wget, chmod, ln, touch, grep, etc ?

vic1972 escribió:si, entiendo que habria que limitar las llamadas a system. Pero estas no se realizan continuamente, sino en momentos puntuales. Por ejemplo: instalar nueva version de PM, ejecutar custom scripts, usuario pida hacer copia de seguridad de fichero canales, etc.

Sí. com comentaba, hay algunas de estas llamadas que sí están justificadas y no parecen problemáticas.

Pero bueno, vale, entiendo que es mejor hacer las cosas de forma "nativa" y no usar busybox porque es un unico fichero de gran tamaño que carga en memoria, mas los problemas de re-entradas.

Exacto.

Los systems que he detectado son para:

wget install bash scripts chmod custom bash scripts cp reboot ln touch grep

Vale, el copy es facil implementar. Pero lo que tu comentas, es que implementemos ( o copiemos) codigo para wget, chmod, ln, touch, grep, etc ?

No; el programador (y más el de sistemas) es vago de nacimiento . Hay system calls fáciles de usar para casi todo. Veamos:

chmod -> man 2 chmod: int chmod(const char *path, mode_t mode);
reboot -> man 2 reboot: int reboot(int magic, int magic2, int cmd, void *arg);
ln -> man 2 symlink: int symlink(const char *oldpath, const char *newpath);
touch -> man 2 open; man 2 close

Luego tenemos cp que como bien dices se puede implementar en 4 líneas. Respecto a grep, no encuentro en el fuente de PM dónde se usa (supongo que será en la versión que estás trabajando ahora para lo del "reply"). ¿Realmente necesitas toda la potencia de las expresiones regulares? si es así hay que usar la librería regex (man 2 regex); sino, si es solo para comparaciones simples entre substrings, entonces se hace "a pelo" o con alguna librería simple de manejo de strings. Luego tenemos wget. En este caso lo mejor es invocarlo directamente con execv de la librería exec (man 3 exec), como en la "maqueta" del uso de pipes internas que puse en un mensaje anterior. De esta forma te evitas invocar al shell (busybox).

Finalmente están las system() que usas para ejecutar shell-scripts. Claro, aquí ya no hay escapatoria: necesitas un shell. Como hemos acordado, esto habría que usarlo para cosas que no se usen normalmente; solo en situaciones excepcionales. Por eso te comentaba que las llamadas para lanzar las "custom shell scripts" sería conveniente sacarlas de PM y hacer un pequeño programa (o quizas bastaría una shell script) solo para eso.

Como te decía en mi anterior mensaje, dime si quieres que vaya yo haciendo algo.

Saludos,

Hello boys why you not write in english?
If I translate last evr message in google translate, I must say the replacing all of these calls will significantly speed up PM execution.

Keltek escribió:Hello boys :) why you not write in english? ;)

Sorry about that; I though only Vic was interested in this discussion

If I translate last evr message in google translate, I must say the replacing all of these calls will significantly speed up PM execution.

Well, not that much because most of the present system() calls in PM are not used heavily. But, on the other hand, I do think the idea of the internal stdin/stdoutpipes proposed above in this thread should significantly improve responsiveness...

Best,

Sorry keltek, you right

WOWWW interesting, i did not know i can use reboot , chmod directly from c program.
everyday i learn a lot
ok, please, help with the wget command,
mean while i am going to have a look and eliminate chmod and reboot system calls.
regards

Hello reboot from c program is not working for me,
any suggestion? ..

I have done:

Código:


#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <linux/reboot.h>
 
int main(void)
  {
    printf("Reboot program, only superuser can call this program :) \n");
   
      int result=reboot(LINUX_REBOOT_MAGIC1,LINUX_REBOOT_MAGIC2,LINUX_REBOOT_CMD_RESTART,"-f");
      printf("Result:%d\n",result);
  return 0;
}


I have tried both linux-pc and lg, with no result, that is , is not resetting, i get output:

root@Venus:~# ./reboot
Reboot program, only superuser can call this program
Result:-1

vic1972 escribió:Hello reboot from c program is not working for me,
any suggestion? [...]

Try this one:

Código:

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <linux/reboot.h>
#include <sys/reboot.h>

int main(void) {
//printf("Reboot program, only superuser can call this program :) \n");
  sync();
  int result = reboot(LINUX_REBOOT_CMD_RESTART);
  printf("Result, errno: %d, %d\n",result,errno);
  perror("Perror");
  return 0;
}

Is better to use the simplified version (defined in sys/reboot.h -- see man 2 reboot). It does work for me!

Best,

vic1972 escribió:[...]ok, please, help with the wget command, [...]

Here you have it. Well, it is slightly more general; you can invoke wget or whatever program which produce some output. The stdout plus stderr are copied to a buffer that you has to pass as an argument; this way you can have some control over the result of executing the program. Please, let me know if this is O.K. or you prefer something different.

Best,

Código:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <errno.h>
#include <signal.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>

/*-----------------------------------------------------------------------
  execOut runs the "server" in argv[0] and puts its stout+stderr into buf[]
  "server" must write at least 1 byte; otherwise execOut never returns 
*/
int execOut(int M, char buf[M], char *argv[]) {
  int  fdout[2]; pipe(fdout);    /* child's ("server") output/error pipe */
  pid_t pid=-1;                                          /* child's PID */
  int  count, status;

  if((pid = fork()) == (pid_t)0) {                /* This is the child  */
    close(1);  dup(fdout[1]);            /* connects stdout to the pipe */
    close(2);  dup(fdout[1]);            /* connects stderr to the pipe */
    execv(argv[0], argv);                    /* child becomes the server */
    return -errno;              /* we can reach here only if execv fails */
  }
  else {                                          /* This is the father */
    if((wait(&status)<0) || status) return -1;  /* waits for child's end */
    count = read(fdout[0], buf, M-1);            /* reads child's output */
    if(count>=0) buf[count] = '\0';
    close(fdout[0]); kill(pid,SIGKILL);
    return count;
  }
}

/*---------------------------------------------------------------------- */
int main(int argc, char *argv[]) {  /* the "server" to run is in argv[1] */
  int count; const int M=16384; char buf[M];
  if(argc<2) {
    fprintf(stderr, "\nUse: %s pathBinProg\n\n", argv[0]); exit(1);
  }
                                /* run "server" & get its output in buf */
  count = execOut(M, buf, argv+1); /* (argv+1)[0] is the "server" to run */
                                  /* (argv+1)[1], ...  are its argments */
  /* another invocation example:
    char *myargv[3]; myargv[0]="/bin/ls"; myargv[1]="-l"; myargv[2]=0;
    count = execOut(M, buf, myargv);
  */
  if(count>0) {
    printf("%s\n", buf); exit(0);
  }
  else {
    fprintf(stderr, "** error %d\n", count); exit(1);
  }
}


thanks, i will test.

reboot is working fine.
The code of PM has been upgraded with your code.
Thanks
Now a piece of PM is thanks to your work

vic1972 escribió:reboot is working fine. The code of PM has been upgraded with your code. Thanks [...]

Thanks to you! Do you want also similar test code for chmod, ln -s and touch? -- hope you can easyly do grep with the function execOut which I posted yesterday: please let me know if you find some trouble with it.

Best,

the little program for wget does not work for me, i think i need some parameters:

[victor@victor wget]$ gcc wget.c
[victor@victor wget]$ ls
a.out Makefile wget.c
[victor@victor wget]$ ./a.out

Use: ./a.out pathBinProg

[victor@victor wget]$ ./a.out [Tienes que estar registrado y conectado para ver este vínculo]
** error -1


Basically it seems we are sending the *command* to the : execv,
is this not creating a re-entrant in busybox..?

vic1972 escribió:the little program for wget does not work for me, i think i need some parameters:
[...]Basically it seems we are sending the *command* to the : execv, is this not creating a re-entrant in busybox..?

Nope. As I said:

evr escribió:[...]it is slightly more general; you can invoke wget or whatever program which produce some output. The stdout plus stderr are copied to a buffer that you has to pass as an argument; this way you can have some control over the result of executing the program. [...]

So, in your example you should invoke (in a linux PC) the test program as:

Código:

./a.out  /usr/bin/wget  http://dl.dropbox.com/u/684543/index.html

or in the LG:

Código:

./a.out  /usr/local/bin/wget  http://dl.dropbox.com/u/684543/index.html

All the work is carriead out by the function:

Código:

execOut(int M, char buf[M], char *argv[])

You have to pass an empty buffer buf with M allocated bytes and a vector of strings. For the wget example, these strings should be:

Código:

argv[0]="/usr/local/bin/wget"
argv[1]="http://dl.dropbox.com/u/684543/index.html"
argv[2]=0

Upon successful execution, you will get in buff the first N bytes that wget will produce in its stdout+stderr. Thanks to execv, busybox is not used at all.

I think it is better to have this more general execOut function, that just one specifically implemented only for wget.

Please let me know if you need more details.

Best,

Hi, thanks, it is working now.

one question
when I pass as parameter /usr/local/bin/wget
this file: /usr/local/bin/wget is in fact a link to busybox

what is the different among using system wget and execOut ...? Seems like i need some reading, but if you could give us some
preliminary ideas ... thanks


Next point, the system touch command, will this be executed the same way as the wget, suging exeOut ..?

/usr/local/bin/wget is not a link, it is a regular file.
If you use system() call, it will create a shell and execute a command you specified.
Execv() ( see [Tienes que estar registrado y conectado para ver este vínculo] ) make a fork() and execute a specified command as a child process - and you can handle stdout/stdin of this forked process (evr, am I right?)
And you can use it in PipeManagement to handle DvdPlayer as child process without piping output back to PipeManagement.

Wonderful thanks for clarification.

vic1972 escribió:[...]one question -- when I pass as parameter /usr/local/bin/wget this file: /usr/local/bin/wget is in fact a link to busybox

Nope! I am not talking about /usr/bin/wget, but /usr/local/bin/wget, which is the only wget you get with the official firmware (the official busybox does not carry wget!). This wget is much simpler and smaller than busybox, and it takes less resources.

what is the different among using system wget and execOut ...? [...]

In official firmware, system("wget") spawns two process, each with a different program: a) busybox to execute sh and b) the wget you need. If you use the wget of newer busibox versions, then you also spawn two (bigger) processes; both running busybox (first the shell and second wget). With execOut only the target process is spawned via fork() (no shell needed by execv). And, if you run the simpler/smaller specific wget program, then you gain quite a lot. Remember that I am aiming at getting PM completely rid of busybox...

Next point, the system touch command, will this be executed the same way as the wget, suging exeOut ..?

Nope ;) It is just direct syscall; I think just open() and close(). I will look in more detail to see if there is a more direct call.

Best,