e2fsprogs utils for Android (EABI ARM)

I've been playing around with my brand new Android (cool Christmas gift from my employer ;).
Because of the security model by default you cannot store apps into /sdcard (only at /data/apps, which is mounted from the internal MTD device), and this is something you'll eagerly want for freakin'ly installing bunch of cool applications.

After some hacking around I could get it to like /data/app as a loop-mount:

/ # df
Filesystem           1k-blocks      Used Available Use% Mounted on
tmpfs                    49564         0     49564   0% /dev
tmpfs                     4096         0      4096   0% /sqlite_stmt_journals
/dev/block/mtdblock3     69120     57248     11872  83% /system
/dev/block/mtdblock5     76544     58596     17948  77% /data
/dev/block/mtdblock4     69120      1256     67864   2% /cache
/dev/block/mmcblk0p1    991488    950448     41040  96% /sdcard
/dev/block/loop0        128949     19098    103186  16% /data/app

, where /dev/block/loop0 is actually a loop mount on /sdcard/data-extra.img ext2 image file.

I will post a more detailed mini-howto about this hack, but the 1st thing you'll need (and I couldn't find out there before) are the e2fsprogs utils built for Android.
So I went ahead, changed some e2fsprogs src bits and compiled with my android sdk arm gcc toolchain (built @my workstation from the Android git repo).

You can find them at:
http://sites.google.com/site/juanjosec/android , namely:
e2fsprogs-android.diff, e2fsprogs-base_arm-eabi.tar.gz, e2fsprogs-xtra_arm-eabi.tar.gz.

15 years have passed since I first touched my 1st Linux, 13 so far since I hacked the Linux kernel for ip aliasing support ... been a long trip, and now I can finally carry it in my pocket ;-)

yeah ... debugging sucks, testing rocks, but ...

I'm by no means a software engineer (well ... neither an electronic engineer nowadays, as my title says :-/ ).

Anyway, the fact is that I usually do some hacking around source code, without a formal approach ... that is: hands on to solve some specific problem and/or implement a new feature and have fun.

To the point: I was touching some code related to the frontend serving infrastructure in my work, it took me ~a couple of hours come up with a src change I could be proud of :) ... just to find out that the respective unit testing additions for this new functionality will end toasting almost twenty hours from me to stabilize (yup ... 10x), and several round trips with the main devel team.

Pheeeeuuuu... testing rocks, but it can be a rock itself, heh ...

Por fin entendí porqué SVN siempre apestó para mí.

... entonces ya puedo redimir mi pecado de no haber aprendido nunca SVN habiendo escapado directamente de CVS a GIT ;-)

Linux Torvalds no sólo habla sobre GIT, sino también sobre conceptos de SCM distribuídos & alike.
Imperdible.

[devel] multi process posix mutex

Jugando con la posibilidad de usar los mecanismos de sincronización de POSIX para threads (pthread_mutex_t, sem_t, pthread_cond_t , etc) llegué a una mini aplicación que es capaz de crear un MUTEX multiproceso de "larga vida" mediante el uso de memoria compartida:

    ./mproc-mutex estelock i  #init
    ./mproc-mutex estelock l  #lock
    ./mproc-mutex estelock l  #lock again: will wait until unlock or signal (eg: Ctrl-C)
    ./mproc-mutex estelock u  #unlock

La clave del fuente está en las sig. líneas:

   int fd; char *p;
   fd=shm_open(argv[1], O_RDWR|O_CREAT, 0666);
   ftruncate(fd, sizeof(pthread_mutex_t));
   :
   p=mmap(NULL, sizeof(pthread_mutex_t), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
   :
   pthread_mutex_init(p, NULL) ;

Más explicaciones en el src: http://www.lugmen.org.ar/~jjo/jjotip/jjotip-mproc-mutex/mproc-mutex.c