Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752556Ab1FUEvO (ORCPT ); Tue, 21 Jun 2011 00:51:14 -0400 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 X-AuditID: b753bd60-a0a78ba0000050a4-4c-4e00233b006b X-AuditID: b753bd60-a0a78ba0000050a4-4c-4e00233b006b Message-ID: <4E002337.1010208@hitachi.com> Date: Tue, 21 Jun 2011 13:51:03 +0900 From: Nao Nishijima User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 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 Subject: Re: [PATCH 1/3] [RFC] genhd: add a new attribute in device structure 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3410 Lines: 80 (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. When you >>>>>> build an enclosure with labels, the label names are stored in a >>>>>> diagnostic page. We can actually interrogate the enclosure directly 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 that >>>>> can handle only one single name. Reality the last years has taught 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 just 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 use >>>> that when stuff is logged. Just the same way the netifs have an alias. >>>> 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 together >>>> and work on the problem, which is that we don't have machine-readable >>>> 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 solution. >> >> OK, fine ... we'll do it as gendisk only then. I suppose that is the >> 95% use case anyway. > > Sounds fine. It's probably easier to have it domain-specific anyway. > Just like the netif alias already is. > 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. > 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. > 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, -- Nao NISHIJIMA Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., YOKOHAMA Research Laboratory Email： nao.nishijima.xt@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/