jaypipes / ghw

Go HardWare discovery/inspection library
Apache License 2.0
1.62k stars 174 forks source link

Properly detect dm devices #298

Open avishayt opened 2 years ago

avishayt commented 2 years ago

With multipath, we currently see that the drive type is "unknown". It would be great to see it as "multipath" or even something more generic such as "mapper", and it would be even greater to see which other devices were associated with it.

jaypipes commented 2 years ago

@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.

ffromani commented 2 years ago

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.

jaypipes commented 2 years ago

@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.