Hello, Unfortunately I don't have the time to review the changes right now (but the overall shape looks like I expected, though I would have kept the io.c file name and the netfs hooks in the same order as the trivfs hooks, so that it gets obvious in the patch that not much code has actually changed).
Mikhail Karpov, le mer. 03 juin 2026 19:47:35 +0700, a ecrit: > settrans -c storeio /hurd/storeio -w -T typed file:/root/disk.img > In this case, to enable the ext2fs translator to work with storeio by > opening partition 2, you need to call: > settrans -c ext /hurd/ext2fs -w -T typed part:2:file:/root/storeio > or > settrans -c ext /hurd/ext2fs -w -T typed file:/root/storeio/2 Yes. > If storeio itself is created with the type part:2:file:/root/disk.img, then > it is sufficient to > settrans -c ext /hurd/ext2fs -w -T typed file:/root/storeio Yes. > It should be noted that regardless of whether you need to work with > the entire disk or a specific partition, the internal structure of > storeio will be created upon request (in the case of working with a > single partition, The directory will only have node 1). Perhaps in > the second case, this behavior is undesirable, I'm not sure I understand what you mean. If there is one partition, yes, the user will need to either set the storeio with part:1, or give ext2fs the part:1 piece, or give it storeio/1. But if there is no partitioning at all (parted reports an error), storeio shouldn't expose a directory. > but I haven't found a simple way to prevent it. Most likely, I'll need > to move struct store_parsed out of libstore/argp.c and work with the > user-supplied command. For what case precisely would you need that? > I also found a strange bug when working with maptime_map. Calling this > function during system boot breaks the boot process, but after boot, > it doesn't cause any problems Ah, libtrivfs doesn't actually call it, that's possibly why we never saw the problem. I guess it gets stuck because maptime_map tries to open /dev/time, because netfs_init tries with use_mach_dev=0 first. That being said libdiskfs does that too. > There are also several functions that I don't understand how to migrate > correctly: trivfs_goaway, trivfs_modify_stat, close_hook, and > trivfs_S_fsys_syncfs. Am I correct in assuming that these > manipulations need to be performed on each open dev? For goaway/close/sync, yes. modify_stat is only for trivfs Samuel
