On Mon, Aug 21, 2017 at 6:51 AM, Julian Elischer <julian_at_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... WarnerReceived on Mon Aug 21 2017 - 12:25:15 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:12 UTC