Conversión de vdrnfofs a C

Este nuevo tema viene en respuesta de este otro

Si has convertido vdrnfofs a C se podría mirar de compilarlo en el giga, ¿todavía depende de fuse?

Sí, y además no se me ocurre otra manera de hacerlo sin fuse....por la tarde miro a ver puedo compilar fuse para ARM.....

La verdad es que no se me había ocurrido que podría servir para el Giga.....así se exportarían directamente por NFS/SMB los mpg...

Luego lo subo a github para que lo mires, en teoría le he pasado valgrind para comprobar los leaks de memoria y solo pierde unos bytes en la llamada a fuse, por lo que más o menos debía de ser seguro, y en mi equipo tiene un rendimiento similar (o quizás un pelín superior) a vdrnfofs.

Si lo crees oportuno casi mueve esta parte a otro hilo nuevo...

Saludos

EDITO:

Parece que se puede compilar fuse para arm, creo que solo necesita las fuentes del kernel, y genera un módulo para insertar luego. Como tengo el entorno para el trunk en una máquina virtual, intentaré a ver si lo puedo compilar, pero seguro que necesitaré ayuda con las opciones del gcc para hacer el "cross-compile"...
Si me dejan un rato los enanos luego pruebo. Ya os iré contando...

Más: Creo que se necesita CONFIG_FUSE_FS=M o Y pero no lo encuentro en el config que veo para el m740 en assembla.....

Realmente hay que compilar FUSE para MIPS y de hecho hace mucho tiempo lo compilé, pero como nuestro kernel es muy viejo hay un bug al montar el sistema de archivos y ni siquiera puedes hacer un "ls".
Encontré un parche que lo solucionaba, pero hay que adaptarlo a nuestro kernel. Aunque son muy pocas líneas se hace la llamada a una función que no existe en nuestro kernel, entonces hay que mirar de implementarla, ver si se llama de otra manera, ...

Si lo encuentro por el disco duro puedo subirlo para ver si alguien se anima, porque es una alternativa interesante al servidor DLNA del giga y también se podría usar djmount para ver contenido de otros servidores DLNA.

Si me puedes poner algo más de información le puedo echar un ojo, pero a la larga, que como todos ando justo de tiempo.
De todas maneras (igual estoy espeso) no le veo utilidad a ver el contenido de otros servidores DLNA, si el giga no tiene potencia para reproducirlo.
Esa es otra, no se que overhead de CPU tiene fuse....

A ver si lo encuentro y este fin de semana lo subo.

Acceder a un servidor DLNA (tendría que transcodificar a MPEG) desde el giga serviría para ver películas que tenemos en un PC o en el router en DivX, Xvid, ...
Simplemente es una opción más.

En teoría se puede compilar fuse:

HowTO compile fuse libraries and examples

Ya probaré....

En ese ejemplo no compila el módulo del kernel y dice "You will need a modified firmware that include fuse.o", pero ¿cómo lo compilas?.
También le falta decir que es necesario crear el dispositivo /dev/fuse en el firmware.
Tampoco me queda claro cómo hace "insmod fuse" si no ha compilado el módulo del kernel y sin /dev/fuse.

El problema es que al compilar este módulo con nuestro kernel se queda colgado al acceder al directorio donde lo has montado, por lo menos a mi.

Aquí comentan cómo compilarlo, pero no usan el compilador egcs, que es con el cual se ha compilado nuestro kernel y los módulos.
Lo correcto es usar el mismo compilador por temas de compatibilidad, pero quizás en este caso esa porquería de compilador sea el problema.
Aquí parece que está el binario compilado con ese método.

Si no recuerdo mal, la prueba que hice compilaba la librería, el módulo y los añadía al firmware junto a /dev/fuse.

bittor, ¿hay algun setenv en el trunk para no volverme loco?

Código:


root@bt:/media/android/fuse/fuse-2.9.2# ./configure --host=mips-linux --disable-kernel-module --prefix=/media/android/m740fuse/
configure: WARNING: unrecognized options: --disable-kernel-module
configure: WARNING: if you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used
checking build system type... i686-pc-linux-gnu
checking host system type... mips-unknown-linux-gnu
checking target system type... mips-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mips-linux-strip... mips-uclibc-strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking how to print strings... printf
checking for style of include used by make... GNU
checking for mips-linux-gcc... mips-uclibc-gcc
checking whether the C compiler works... no
configure: error: in `/media/android/fuse/fuse-2.9.2':
configure: error: C compiler cannot create executables
See `config.log' for more details



Alaaa...justo..XD

Me tengo que ir, a ver si luego le pego un vistazo...

Gracias!!

gafe escribió:bittor, ¿hay algun setenv en el trunk para no volverme loco?

Lo que se hace para compilar un programa usando el ToolChain es establecer las variables CC, CFLAGS, ... con las del TC, entonces si el programa no es muy especial y no tiene dependencias raras se compila sin problemas.
Esto se hace de manera sencilla con los archivos make-incs\*.mk, si miras alguno como por ejemplo "e2fsprogs.mk" verás que simplemente se hace un configure + make + make install.
Puedes crear uno nuevo cambiando "e2fsprogs" por el nuevo programa (respetando mayúsculas y minúsculas, es decir, e2fsprogs y E2FSPROGS son distintos).

Para ver las variables de entorno que se usan, puedes editar el archivo Makefile que está en el raíz del Toolchain y mirar estas variables:
UCLIBC_ENV -> los flags estándar
UCLIBC_ENV_GC -> reduce binarios eliminando secciones no usadas
UCLIBC_ENV_LTO -> usa Link Time Optimization
UCLIBC_ENV_LTO_GC -> usa Link Time Optimization y elimina secciones no usadas
UCLIBC_ENV_SIZE -> optimización para reducir el tamaño al máximo sin importar el rendimiento

Si usas UCLIBC_ENV tendría que funcionar bien y los demás se usan según el programa para hacer diversas optimizaciones y pueden fallar al compilar algunos programas, por ejemplo en el e2fsprogs se usa UCLIBC_ENV_SIZE porque queremos el mínimo tamaño y nos da igual el rendimiento.

A ver si todavía tengo lo del FUSE por el disco y puedes ver cómo lo compilé.

Pues ya lo he encontrado.
Lo he subido aquí, simplemente es copiarlo en el ToolChain y ejecutar:

Código:

echo CONFIG_FUSE = y>> .config

Al ejecutar make se bajará fuse 2.5.3, se compilará la librería, el módulo del kernel y la utilidad fusermount.
El firmware también se generará con /dev/fuse.

Es posible que según los programas/plugins que tengas configurados en el .config no te quepa en el firmware, simplemente editas el .config y estableces la compresión LZMA

Código:

CONFIG_SQUASHFS_LZMA = y

y ejecutas

Código:

make distclean-squashfs-host distclean-siemens-linux-kernel

para que se genere el firmware con esta nueva compresión.

Esto fue una prueba y no funciona, pero he dejado estos dos parches que supuestamente arreglaban el cuelgue al hacer el ls del punto de montaje:
113-DCACHE_BUG.patch -> usa "r4k_flush_cache_page" pero en nuestro kernel tenemos 10 funciones que empiezan por "r4k_flush_cache_page" en el archivo "build/slin_m740_pro/arch/mips/mm/c-r4k.c" pero ninguna "r4k_flush_cache_page".
113-hang-fix.patch.bak -> supongo que seguía fallando, pero no lo recuerdo bien.

Tal y como está no funciona y fallará al hacer el insmod porque "r4k_flush_cache_page" no existe en nuestro kernel, pero puedes renombrar "113-DCACHE_BUG.patch" con extensión .bak y volver a compilar fuse con "make clean-fuse distclean-fuse && make".

Ok, lo probaré ... gracias...

Bueno , he tenido 5 minutos ahora y he conseguido subir el código a github:

https://github.com/miguel-cv/vdr_fuse

Miradlo los que sepais C , que es mi primer programa y seguro que tiene algunas gambadas...en principio llevo usándolo 4 o 5 días sin problemas aparentes.

@bittor:
He estado viendo lo que comentas y efectivamente parece ser que para los kernels viejos como el nuestro da problemas, unas versiones después lo arreglaron, que justo...
En teoría se puede cambiar el código de fuse para que no necesitemos /dev/fuse y usar p.ej /tmp/fuse , pero sí he visto esto que dice que en teoría funcionaba:

compilación kernel m740 y módulos

Un poco más abajo compila fuse....y nos deja el trabajo hecho aquí:

http://web.dit.upm.es/~jantonio/m740av/

(buscar el archivo fuse....)

Lo he bajado, pero de momento no podré dedicarle tiempo, a ver estos días si saco 5 minutos y lo meto en el giga...

Saludos

Gracias por la info y el programa, revisaré los parámetros que se usan en el howto para ver si así al menos el fuse no se cuelga y si todo va bien probaré a compilar tu programa para el giga.

Creo que no valen los archivos de ese paquete, la versión con la que fueron compilados es distinta de la actual:

./fusermount: can't resolve symbol '__uClibc_start_main'

y aparte el script mount.fuse necesita bash...

También he intentado hacer un mount --bind para meter en / el contenido del paquete y hace el montaje pero no me coloca las cosas en su sitio.

Total, que hay que compilarlo todo otra vez .... veremos por la tarde...

He visto en el parche esto:

#if defined(__arm__) && LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)

con lo poco que entiendo, creo que esto significa que se aplicará el parche cuando la versión del kernel sea < 2.6.20 Y estemos en arquitectura ARM. Por eso seguramente te fallaba el parche.
si lo dejamos así:

+//#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
+#define DCACHE_BUG
+//#endif
+

debía de aplicarse el parche. Por eso no te funcionaba, porque no se aplicaba el parche. Pone:

/ patch from mailing list, it is very important, otherwise,
+ // can't mount, or ls mount point will hang
+ flush_cache_all();

gafe escribió:Creo que no valen los archivos de ese paquete, la versión con la que fueron compilados es distinta de la actual:

./fusermount: can't resolve symbol '__uClibc_start_main'

Si usas los archivos que puse antes tendrás el fusemount compilado con nuestro uClibc, así todavía podrías usar el módulo del kernel suyo y la utilidad fusermount compilada para nuestro firm.

gafe escribió:y aparte el script mount.fuse necesita bash...

Puedes editar el archivo .config y añadir bash al firmware con "CONFIG_BASH = y", pero no creo que sea necesario usar ese script.

gafe escribió:He visto en el parche esto:

#if defined(__arm__) && LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)

con lo poco que entiendo, creo que esto significa que se aplicará el parche cuando la versión del kernel sea < 2.6.20 Y estemos en arquitectura ARM. Por eso seguramente te fallaba el parche.
si lo dejamos así:

+//#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
+#define DCACHE_BUG
+//#endif
+

debía de aplicarse el parche. Por eso no te funcionaba, porque no se aplicaba el parche.

Ops! una línea con // es un comentario
Por lo tanto da igual que en la línea ponga arm o no y sí que lo aplica porque al hacer insmod dice que el símbolo "r4k_flush_cache_page" no está exportado (o algo similar) y es el que no tenemos en nuestro kernel.

gafe escribió:Pone:

/ patch from mailing list, it is very important, otherwise,
+ // can't mount, or ls mount point will hang
+ flush_cache_all();

Intenté ejecutar sólo ese trozo con el parche "113-hang-fix.patch.bak" pero si no recuerdo mal seguía fallando porque sino lo hubiera subido al SVN.

Arghhh tienes razón en todo lo que dices....
Una cosa que he visto por ejemplo en este parche:

https://dev.openwrt.org/attachment/ticket/4754/2.6.36__170-kmod-fuse-dcache-bugfix.patch

es que modifican el archivo arch/mips/mm/c-r4k.c del kernel para exportar la función:

Código:


diff -Nurp a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c a     b     static inline void local_r4k___flush_cac
373   373           }
374   374   }
375   375   
376       static void r4k___flush_cache_all(void)
    376   /* make flush cache available for export */
    377   void r4k___flush_cache_all(void)
377   378   {
378   379           r4k_on_each_cpu(local_r4k___flush_cache_all, NULL, 1);
379   380   }
…   …    void __cpuinit r4k_cache_init(void)
1469   1470           coherency_setup();
1470   1471   #endif
1471   1472   }
    1473   
    1474   /* fuse package DCACHE BUG patch exports */
    1475   void (*fuse_flush_cache_all)(void) = r4k___flush_cache_all;
    1476   EXPORT_SYMBOL(fuse_flush_cache_all);


y sin embargo no está en los parches que tienes tú.

A ver si de una vez le puedo dedicar diez minutos seguidos a esto.

P.D. Para que compile el programa hay que cambiar define FUSE_USE_VERSION por una anterior,25,21 o similar...
P.D. Ya consigo que compile bien el trunk con fuse, me falta meter el programa en el directorio example, meterlo en el lst y luego cuando me deje la parienta instalar el firmware en el Giga y probar que funcione todo. !Ah! y meter antes el parche del c-r4k a ver que pasa XD