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

Hello,

On Sun, 26 Apr 2026 22:20:21 Samuel Thibault wrote:

 > You mean, only telling storeio.static what drive it should be using, and
 > not ext2fs.static, right?
Yes

 > 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?
Shouldn't we do something similar to diskfs_start_bootstrap from
libdiskfs/boot-start.c?

 > 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 not just making storeio_bootstrap_startup use &storeio_fsys rather
 > than &control?

Hmm, I thought that for libmachdev to work I would have to work with 
control,
but I checked and replaced all the &control with &storeio_fsys and nothing
broke... This makes things a lot easier.

 > > +task_t parent_task = MACH_PORT_NULL;
 >
 > Do we really need to expose this? Can't both libmachdev and storeio make
 > an fsys_getpriv call to get it without having to share?

Since I was trying to replicate machdev_trivfs_init exactly inside
storeio_bootstrap_startup, I expanded parent_task, but perhaps it's not
necessary to do it exactly. In any case, parent_task is required by
trivfs_S_fsys_init from libmachdev, so something will need to be done about
that.

Thanks,

Mikhail Karpov