Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Aug 2017 09:25:13 -0500
From:      Warner Losh <imp@bsdimp.com>
To:        Julian Elischer <julian@freebsd.org>
Cc:        freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: mapping a device from device-id to /dev
Message-ID:  <CANCZdfp%2BG5P_U=kYrKGiups-aHrfGSBtKHnLCPu2ogpGNnSgpQ@mail.gmail.com>
In-Reply-To: <cde94d2d-1e1c-7641-ddb4-f10623e6807f@freebsd.org>
References:  <cde94d2d-1e1c-7641-ddb4-f10623e6807f@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 21, 2017 at 6:51 AM, Julian Elischer <julian@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...

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfp%2BG5P_U=kYrKGiups-aHrfGSBtKHnLCPu2ogpGNnSgpQ>