Hello, Mikhail Karpov, le lun. 27 avril 2026 22:42:48 +0700, a ecrit: > On Sun, 26 Apr 2026 22:20:21 Samuel Thibault wrote: > > You are passing the task as argument to store_create, but store_create > > expects a file_t, not a task. So it's not surprising to be getting > > MIG_BAD_ID, RPCs to a task are actually going to the kernel :) > > > So the problem now is that you want to get a file_t from the storeio > > process, instead of ext2fs opening the device by itself. That would > > usually be through fsys_getroot on the control port of the storeio > > process, which it can get from the special port. > > Oh, that clears things up a lot. So, the argument parsing step won't allow > opening the store, because that should happen in diskfs_startup_diskfs, > right?
Opening the store can be done provided that you have the bootstrap port. And you have it from the special port, you can just pick it up with task_get_bootstrap_port and use it. You just need to make sure that storeio resumes the next task after being ready to serve file_get_storage_info. > Shouldn't we do something similar to diskfs_start_bootstrap from > libdiskfs/boot-start.c? Not sure what you mean. You don't need to interact with exec etc. before interacting with storeio and rumpdisk. > > Actually, I'm wondering whether we need to involve libmachdev at all in > > the end: since we can make ext2fs open storeio through the control port, > > it doesn't need to get it through a device interface. > > I tried to do without libmachdev, but without demuxer from > libmachdev the boot fails, because trivfs_demuxer does not provide > device_server_routine. Why would you need the device server? ext2fs only needs to call file_get_storage_info from storeio. You can make storeio pass a copy of the master device port from its parent in its fsys_getpriv() RPC, instead of its own control port, so that device_open() etc. directly go to rumpdisk etc. Samuel
