device backends need a persistent identifier for use in debugging

[jclulow]

Picture if you will: three Crucible disks attached to a VM, firing DTrace probes that are being observed by an engineer. That engineer has, at present, no way to know which probe firings are related to which disk in the system.

We should like to have a away to distinguish different backends from one another, ideally based on something that will be persistent between two identically configured Propolis instances. Obviously a uint64_t of some kind would be the cheapest thing, but a short static string would be a close second; e.g., by using some rendering of the PCI slot/path in the emulated system.

I expect this would be something we would be handed by Propolis on whatever context object we get passed at backend instantiation time.

[leftwo]

Crucible does have a "session_id" that was added to some probes, but this is not easy to tell what
virtual disk it belongs to. In addition, a single virtual disk may have both a read only parent and a
read write region associated with it, and that difference is not visible to propolis.

[pfmooney]

Obviously a uint64_t of some kind would be the cheapest thing, but a short static string would be a close second; e.g., by using some rendering of the PCI slot/path in the emulated system.

I expect this would be something we would be handed by Propolis on whatever context object we get passed at backend instantiation time.

The structure of the block layer in propolis complicates this a little bit. The frontend (device emulation) and backend (crucible) are each initialized independently before being associated in an attach operation. If crucible is amenable to having such an identification context passed to it during the attachment process, then it should be fairly straightforward.

[leftwo]

I'm sure we can make Crucible amenable if it's not already :)