Re: [PATCH] Adding-storeio-to-the-bootstrap-chain.

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