From owner-freebsd-geom@freebsd.org Tue Sep 12 14:21:52 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18A06E0BD80; Tue, 12 Sep 2017 14:21:52 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2BE6973B45; Tue, 12 Sep 2017 14:21:47 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA13294; Tue, 12 Sep 2017 17:21:46 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1drm4Q-000Nyp-9w; Tue, 12 Sep 2017 17:21:46 +0300 Subject: Re: "unspoilable" geom labels To: Warner Losh Cc: freebsd-geom@FreeBSD.org, freebsd-scsi@FreeBSD.org References: <648bcd86-5ef8-b58e-ed04-48880f867fc0@FreeBSD.org> From: Andriy Gapon Message-ID: Date: Tue, 12 Sep 2017 17:20:50 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 14:21:52 -0000 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