after exploring udisks2/libblockdev/libfdisk, I have three possible proposals for resolution:
1. hack udisks2 udisks_linux_partition_table_update
* calling bd_part_get_disk_spec is always going to be a loop, unless
* watches have been inhibited
* or calling bd_part_get_disk_spec causes
ID_PART_TABLE_TYPE to be set
* disable everything under `if (!part_type && num_parts > 0)`, log
and bail
2. add read-only API in libblockdev so we open the dev RO in libfdisk
3. add vtoc support to libfdisk + enable the s390 bits in libblockdev
only option 1 sounds plausible to me, though, for a Mantic timeframe.
after exploring udisks2/ libblockdev/ libfdisk, I have three possible proposals for resolution:
1. hack udisks2 udisks_ linux_partition _table_ update get_disk_ spec is always going to be a loop, unless get_disk_ spec causes PART_TABLE_ TYPE to be set
* calling bd_part_
* watches have been inhibited
* or calling bd_part_
ID_
* disable everything under `if (!part_type && num_parts > 0)`, log
and bail
2. add read-only API in libblockdev so we open the dev RO in libfdisk
3. add vtoc support to libfdisk + enable the s390 bits in libblockdev
only option 1 sounds plausible to me, though, for a Mantic timeframe.