Closed cnuke closed 5 months ago
@cnuke just to confirm, do you wish your vfs_lwext4 branch being merged to staging as is? I'd just leave out the "fix leaking ext4_dir objects" commit, right?
@nfeske I intentionally left out the fixed label because in its current state there are obvious bugs (or short-comings as I put it diplomatically) that compromise proper operation. Since I don't know when I am going to pick this up again (or if somebody else steps forward) I am hestitant to include it in the repository and would rather keep it on a topic branch and keep this issue open (to raise awareness).
Thanks @cnuke or the quick clarification. That's all good and all I wanted to know. ;-)
I'll close this issue as the already existing vfs_lwext4
plugin will be/is maintained elsewhere.
I wrote an experimental VFS plugin for accessing Ext2/3/4 file-systems based on the
lwext4
library. In contrast to the already existinglwext4_fs
file-system server it uses the VFS to access the the underlying block-device but still operates in a synchronous fashion (the back end dispatches I/O signals until the block request was completed).For the time being it works well enough for r/o access and for r/w in case of the
test-libc_vfs
test. There is the genode/vfs_lwext4 branch that adds support for using the plugin in Sculpt. However, doing so denotes current short-comings with plugin. For one newly created directories and files are not picked up bydepot_query
, e.g. after preparing the depot the depot selection in the leitzentrale remains empty. What is more pressing though, writing via this plugin after an forceful un-use/use cycle - in this case the depot selection normally picks up the depot content - corrupts the file-system.I will not spend more time on the plugin in the immediate future but letting it rot on a topic-branch seems too wasteful.