From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nao Nishijima Subject: Re: [PATCH 1/3] [RFC] genhd: add a new attribute in device structure Date: Tue, 21 Jun 2011 13:51:03 +0900 Message-ID: <4E002337.1010208@hitachi.com> References: <20110616181943.GB1439@kroah.com> <1308256290.2436.143.camel@mulgrave> <1308264321.2436.161.camel@mulgrave> <1308320844.2586.14.camel@mulgrave> <1308322193.2586.30.camel@mulgrave> <20110617162247.GA16261@kroah.com> <1308426017.2586.1273.camel@mulgrave> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mail9.hitachi.co.jp ([133.145.228.44]:50497 "EHLO mail9.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751706Ab1FUEvJ (ORCPT ); Tue, 21 Jun 2011 00:51:09 -0400 In-Reply-To: Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Kay Sievers Cc: James Bottomley , Greg KH , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, jcm@redhat.com, hare@suse.de, stefanr@s5r6.in-berlin.de, yrl.pp-manager.tt@hitachi.com (2011/06/19 4:55), Kay Sievers wrote: > On Sat, Jun 18, 2011 at 21:40, James Bottomley > wrote: >> On Fri, 2011-06-17 at 09:22 -0700, Greg KH wrote: >>> On Fri, Jun 17, 2011 at 06:12:14PM +0200, Kay Sievers wrote: >>>> On Fri, Jun 17, 2011 at 17:39, Kay Sievers = wrote: >>>>> On Fri, Jun 17, 2011 at 16:49, James Bottomley >>>> >>>>>> So this is subsystem specific. For the case of a SCSI enclosure= , I can >>>>>> answer that it's actually burned into the enclosure firmware. W= hen you >>>>>> build an enclosure with labels, the label names are stored in a >>>>>> diagnostic page. We can actually interrogate the enclosure dire= ctly or >>>>>> use the ses driver to get these names mapped to current devices. >>>>> >>>>> To me this sounds like a nice name on top of the current bunch of >>>>> names, not like a 'preferred' name. >>>>> >>>>> I still don't like to introduce any new facility to the kernel th= at >>>>> can handle only one single name. Reality the last years has taugh= t us >>>>> a very different story, and we've walked a long way to get where = we >>>>> are. I really don't believe single names will ever work, it's jus= t a >>>>> nice theory. >>>> >>>> I might need to clarify this a bit. >>>> >>>> I have no problem in general to add a 'alias' to every disk, and u= se >>>> that when stuff is logged. Just the same way the netifs have an al= ias. >>>> Sure, it might be useful for some use cases. And if that helps to >>>> solve any real problem, we should just do it. >>>> >>>> I just want to make clear, that I don't think that it is anywhere = near >>>> to a solution for the problems which are described here. And that >>>> nobody should see this as an excuse not to get their stuff togethe= r >>>> and work on the problem, which is that we don't have machine-reada= ble >>>> error and debug from the kernel and a smart syslog. >>>> >>>> If we had that, I'm very sure nobody would even ask for a 'pretty >>>> name' in the kernel, and I think that is a good indication that we= are >>>> not on the right track here. >>> >>> And I totally agree here, which is why I don't want to accept this >>> change to the driver core to add this, as it's not the correct solu= tion. >> >> OK, fine ... we'll do it as gendisk only then. I suppose that is th= e >> 95% use case anyway. >=20 > Sounds fine. It's probably easier to have it domain-specific anyway. > Just like the netif alias already is. >=20 Agreed. Our purpose is to output disk's alias name in kernel messages. > I would suggest not to call it 'preferred' though, but something > similar to 'alias'. Having /dev/disk/by-preferred/ doesn't sound too > convincing to me. >=20 OK, I will change 'preferred name' to 'alias name'. > An 'change' uevent when the alias is set sounds fine. I don't think a > set-once policy is needed. >=20 I will intent to implement as follows - Change the name from preferred to alias - Add alias_name in gendisk - Notify 'change' uevent when the alias is set Thanks, --=20 Nao NISHIJIMA Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., YOKOHAMA Research Laboratory Email=EF=BC=9A nao.nishijima.xt@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html