> > So what is the proper way to do this? > A VFS plugin may only use very limited LibC functionality. In many > aspects this constellation could be compared to the execution of an > application program inside the kernel on Linux. So it's tricky to get > right and stable. I suggest to look for other options if pthreads > and/or blocking file-system operations come into play. > > Beside that you may look into a prior discussion on this list [1] and > the FUSE genode-world issue [2] (esp. Norman's reply [3]) for > inspiration. > > [1] https://lists.genode.org/pipermail/users/2021-November/007828.html > [2] https://github.com/genodelabs/genode-world/issues/193 > [3] https://github.com/genodelabs/genode-world/issues/193#issuecomment-985327 > 679
The wolftpm's page says their code is tuned for portability and has no external dependancy, so who knows, maybe could be feasible ? In case it is, thought I'd give additional inspiration about this: In my specific case, I intended to make the ntfs-3g driver available in Genode ; in the end I realized it basically depends on open()/read()/write()/close() and the like, so that was feasible. What does it look like? Well it's not available from my repo yet, but cnuke was kind enough to make a backup copy of my code on github, look in particular for file "directfs_libc.cc" here: https://github.com/genodelabs/genode-world/commit/b4c5ebea3ea8fa28243310854d594c3afb99a38f#diff-8b00c8a3ce98aa620c2d30ec61ce550d9a661a5bb75b3b4389aee077e04c74b9 I patched an existing Genode-labs file, added a big "extern C...." block (sans aliasing the function names for now). It's ugly as sin (I tend to go "field expedient" when in a major hurry), but might give an idea of how un-complicated the concept is, provided you have a back-end for your pseudo libc. On a more general note... Grep'ping through the genode and genode-world repos for re-implementations of strlen(), malloc(), or even open/read/close(), one finds quite a few hits (including the oldest one, from the original repo/demo folder! :-). Then there's my effort mentionned above. Then there will be (?) Stefan's new effort. That's a few instances of duplicated effort/wheel re-inventing. So it might make sense to consolidate all of this a little bit in the future, i.e. Genode could provide not only their full-fledged LibC based on FreeBSD libc, but also a "micro-libc" for projects that are content with a small subset of libc features including a malloc()/free() pair based on a simple allocator, and so on. Such a 'mini-C' variant would probably require a bit more effort from the user (like "you need to call this initializer at such point from your code, you need to provide a back-end for read/write", etc), but they would be happy to at least have such a trade-off available, instead of facing a rewrite of their libC-using code to make it Genode-API-using code :-). Food for thought. Cedric _______________________________________________ Genode users mailing list [email protected] https://lists.genode.org/listinfo/users
