From: Nao Nishijima <nao.nishijima.xt@hitachi.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
Greg KH <greg@kroah.com>,
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
Date: Tue, 21 Jun 2011 13:51:03 +0900 [thread overview]
Message-ID: <4E002337.1010208@hitachi.com> (raw)
In-Reply-To: <BANLkTin6xfEv85v2BnN1hOuCKtQfzc1Eiw@mail.gmail.com>
(2011/06/19 4:55), Kay Sievers wrote:
> On Sat, Jun 18, 2011 at 21:40, James Bottomley
> <James.Bottomley@hansenpartnership.com> 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 <kay.sievers@vrfy.org> 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-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-06-21 4:51 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-15 8:16 [PATCH 0/3] [RFC] Persistent device name using preferred name Nao Nishijima
2011-06-15 8:16 ` [PATCH 1/3] [RFC] genhd: add a new attribute in device structure Nao Nishijima
2011-06-15 14:43 ` James Bottomley
2011-06-15 15:33 ` Greg KH
2011-06-16 12:03 ` Nao Nishijima
2011-06-16 15:41 ` Greg KH
2011-06-16 15:50 ` James Bottomley
2011-06-16 16:14 ` Greg KH
2011-06-16 16:25 ` James Bottomley
2011-06-16 17:09 ` Kay Sievers
2011-06-16 17:20 ` Kay Sievers
2011-06-16 18:00 ` Douglas Gilbert
2011-06-16 18:05 ` Kay Sievers
2011-06-16 18:15 ` Douglas Gilbert
2011-06-16 18:31 ` Kay Sievers
2011-06-16 21:25 ` Stefan Richter
2011-06-17 6:27 ` Hannes Reinecke
2011-06-17 12:28 ` Nao Nishijima
2011-06-17 11:36 ` Nao Nishijima
2011-06-16 18:19 ` Greg KH
2011-06-16 20:31 ` James Bottomley
2011-06-16 22:05 ` Kay Sievers
2011-06-16 22:45 ` James Bottomley
2011-06-16 23:04 ` Kay Sievers
2011-06-17 11:53 ` Masami Hiramatsu
2011-06-17 14:30 ` Kay Sievers
2011-06-17 14:27 ` James Bottomley
2011-06-17 14:40 ` Kay Sievers
2011-06-17 14:49 ` James Bottomley
2011-06-17 15:39 ` Kay Sievers
2011-06-17 16:12 ` Kay Sievers
2011-06-17 16:22 ` Greg KH
2011-06-18 19:40 ` James Bottomley
2011-06-18 19:55 ` Kay Sievers
2011-06-21 4:51 ` Nao Nishijima [this message]
2011-06-19 1:54 ` Kyle Moffett
2011-06-19 4:14 ` James Bottomley
2011-06-17 6:55 ` Stefan Richter
2011-06-17 5:25 ` Greg KH
2011-06-17 15:41 ` Douglas Gilbert
2011-06-17 15:57 ` Kay Sievers
2011-06-17 3:33 ` Masami Hiramatsu
2011-06-17 5:22 ` Greg KH
2011-06-17 8:15 ` Masami Hiramatsu
2011-06-16 17:32 ` Douglas Gilbert
2011-06-16 18:02 ` Al Viro
2011-06-16 22:48 ` James Bottomley
2011-06-15 8:16 ` [PATCH 2/3] [RFC] sd: print preferred name in kernel messages Nao Nishijima
2011-06-15 8:16 ` [PATCH 3/3] [RFC] fs: print preferred name in procfs messages Nao Nishijima
2011-06-15 15:37 ` [PATCH 0/3] [RFC] Persistent device name using preferred name Greg KH
2011-06-17 5:58 ` Nao Nishijima
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E002337.1010208@hitachi.com \
--to=nao.nishijima.xt@hitachi.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=greg@kroah.com \
--cc=hare@suse.de \
--cc=jcm@redhat.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=stefanr@s5r6.in-berlin.de \
--cc=yrl.pp-manager.tt@hitachi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox