Hello,

Thanks for continuing the work!

Mikhail Karpov, le jeu. 21 mai 2026 15:28:59 +0700, a ecrit:
> I've expanded the functionality of the partfs translator to work with
> multiple disks and their partitions. Thus, by running the command:
> settrans -c partfs /hurd/partfs /root/disk1.img /root/disk2.img
> /root/disk3.img

This way of managing the multiple disks seems to me it would be
confusing for users, and doing more than it should be. We of course
don't want to require users to set a partfs translator by hand with
the enumeration of the disks to be handled, we want that to be
automatic. And if we make it automatic, just numbering the entries
inside the partfs directory will prevent users from knowing what these
devices actually are: usb sticks, sata disks, etc. I believe we do want
to keep the underlying driver device name such as wd0. But then it's not
really useful to have just one partfs that would contain all disks, we
can as well just have one partfs per disk.

And then, as I mentioned previously, I think we want to integrate this
partitioning support with storeio, because:

> +kern_return_t
> +netfs_S_io_read (struct protid *user, data_t *data,
> +                 mach_msg_type_number_t *datalen, off_t offset,
> +                 vm_size_t amount)

> +kern_return_t
> +netfs_S_io_write (struct protid *user, const_data_t data,
> +                  mach_msg_type_number_t datalen, off_t offset,
> +                  vm_size_t *amount)

> +error_t
> +netfs_file_get_storage_info (struct iouser *cred, struct node *np,
> +                             mach_port_t **ports,
> +                             mach_msg_type_name_t *ports_type,
> +                             mach_msg_type_number_t *num_ports,
> +                             int **ints,
> +                             mach_msg_type_number_t *num_ints,
> +                             off_t **offsets,
> +                             mach_msg_type_number_t *num_offsets,
> +                             char **data,
> +                             mach_msg_type_number_t *data_len)

These are replicating a lot of the storeio logics, which we'd rather
avoid, to avoid having yet more code to maintain. We can just migrate
storeio into using netfs rather than trivfs, and make its root behave
like before, except it additionally implements get_dirents, and the
nodes thusly exposed can behave like a parted-based storeio. Essentially
that's a convergence of your current partfs and the existing storeio,
throwing away some parts of each.

That way, we don't actually even need to change the way we expose /dev
entries atm, and people can start using /dev/wd0/1 with the newer
storeio.

> +error_t
> +netfs_get_dirents (struct iouser *cred, struct node *dir, int entry,
> +                   int nentries, char **data, mach_msg_type_number_t 
> *datacnt,
> +                   vm_size_t bufsize, int *amt)
> +{
> +  debug ("netfs_get_dirents (cred: %p, dir: %p, entry: %d, nentries: %d, "
> +         "datacnt: %u, bufsize: %u, amt: %d)\n", cred, dir, entry, nentries,
> +         *datacnt, bufsize, *amt);
> +
> +  if (!dir->nn->entries)
> +    {
> +      debug ("!dir->nn->entries\n");
> +      debug ("netfs_attempt_lookup end with ENOTDIR\n");
> +      return ENOTDIR;
> +    }

And notably that does get sense: if the disk is not partitioned, it's
not a "directory" :)

Another good reason for keeping storeio and partfs together is that
when the user uses fdisk to change the partitioning, we need partfs
to be aware of it and re-parse the partitions to change the exposed
nodes. The simplest way to achieve this coherently is to have only one
translator responsible for exposing the disk to users, which both gets
the BLKRRPART ioctl call from fdisk, and exposes partitions to users.

With regards,
Samuel

Reply via email to