@avishayt @fromanirh I am hesitant to support multipath "devices" just like I am hesitant to support loopback devices.

This hesitation is especially true for mapper "devices" which aren't really devices at all and represent an abstraction above devices.

That's a good point indeed. These are abstractions provided by the linux kernel which happen to be presented using the same interface as the real devices. From this perspective it is out of scope from a hardware abstraction library.

Maybe it's too early, but it seems there it seems to be a trend emerging about features like DM and loopback which are not hardware proper but are traditionally modeled as block devicse and are similar enough to hardware to have a real use cases.

I'm really thinking aloud, but maybe a way forward could be worth to have something like a ghw companion/extension library to handle pseudo devices? I'll file a issue in the future to discuss this option.

@avishayt @fromanirh I might be convinced to add an entirely separate Go package for devicemappers, though. Such a package would treat device mappings/mappers as a separate construct (that would reference pkg/block.Disk structs within it.