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
