Date: Tue, 12 Sep 2017 17:20:50 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-geom@FreeBSD.org, freebsd-scsi@FreeBSD.org Subject: Re: "unspoilable" geom labels Message-ID: <bf7049ca-266d-2f4c-50d2-00530434286b@FreeBSD.org> In-Reply-To: <CANCZdfrVVfxC655v0fhT=h0fciVxyS8xmt5vOVWpjkp-fPGPqg@mail.gmail.com> References: <648bcd86-5ef8-b58e-ed04-48880f867fc0@FreeBSD.org> <CANCZdfrVVfxC655v0fhT=h0fciVxyS8xmt5vOVWpjkp-fPGPqg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/09/2017 16:28, Warner Losh wrote: > The CAM code expects to be able to map the name 'da0' to 'pass14' so it can send > the passthrough devices. It has no clue about device names, apart from passXXX > it has to open to send the commands for the thing named 'da0'. In fact, it has > no clue at all about the upper layers at all. I would argue that it would be > quite difficult, given the current state of geom, to properly guess. It > shouldn't even try. Bad things can only come from accidentally guessing wrong. I mean that maybe it's not exactly the job of a function like cam_get_device(), maybe it's a job if its callers (like camcontrol), but at the very least we could check if /dev/$name is a symlink and resolve it. I assume that the valid device names always corresponding devices entries under /dev. And, yes, mapping a GEOM label to an original name is harder than it should be with the current implementation. Maybe it would be easier with labels implemented as aliases. > Instead, if you really want this functionality, we should create either an ioctl > to get this information (perhaps in a list for the case of gmirror, but perhaps > not) or a bio attribute that could be synthesized properly. The third vehicle > for this would be to put the attribute in the config for geom, but that's a bit > of a pain. I agree. Maybe such a method would be a good thing to have regardless of the labels implementation. > Then again, you can't easily map an entry from /dev into a device_t that > implements it (if any). You can't map a cam device, even, to a device_t either, > just as far as the SIM if you look hard enough. I think that this is a little bit different issue. I think that getting from e.g. /dev/diskid/DISK-MK0351YVKNNX3A to e.g. /dev/ada77 should be sufficient for most userland utilities. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bf7049ca-266d-2f4c-50d2-00530434286b>