On Mon, Aug 21, 2017 at 6:51 AM, Julian Elischer <jul...@freebsd.org> wrote:

> I have the following (Azure) device (disk) id:
> dev.storvsc..%pnpinfo: classid=32412632-86cb-44a2-9b5c-50d1417354f5
> deviceid=00000000-0001-8899-0000-000000000000
> the question is:  "how can I map that do /dev/da1"..

You can't. Partially because it's also da1p1, da1p2, etc as well. Partially
because storvsc is a SIM and can have multiple devices, partially because
there's no device_t to SIM mapping, let alone to the dev_t for the disk
drive (and even then you have geom to worry about too).

> I know that for my device it IS /dev/da1
> but how can I prove it? there are so many mappings from one space to
> another I've totally lost track.
> there are acpi mappings, pnpmappngs, /dev/ mappings, PCI space mappings,
> things in sysctl, things in their own spaces, etc. etc.
> In some architectures htere are fdt mappings and in some it's still pretty
> random from what I see.

Yes. There's no way to map, generically, a device_t to a dev_t. In fact,
the above sounds like a CAM device, which doesn't even have a device_t,
just the device_t of the SIM. storvsc is the SIM that you're lucky has only
one device attached. mpt can (and does) have a dozen attached to it.
There's also the issue that we create separate devices for each way we
present the device to the user: /dev/ufs/lable, /dev/ufsid/numbers,
/dev/gpt/name, /dev/gptid/numbers, etc.

> Is there a document that covers all of these?

/usr/src/sys, sadly

I have a similar issue getting the full, physical map to drives for UEFI.
Thankfully, I can use logical names for that. I'm slogging through
implementing things, though, its tough going...

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to