From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Greg KH <greg@kroah.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
Nao Nishijima <nao.nishijima.xt@hitachi.com>,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
kay.sievers@vrfy.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: Fri, 17 Jun 2011 12:33:05 +0900 [thread overview]
Message-ID: <4DFACAF1.3010300@hitachi.com> (raw)
In-Reply-To: <20110616161442.GA32113@kroah.com>
(2011/06/17 1:14), Greg KH wrote:
> On Thu, Jun 16, 2011 at 11:50:54AM -0400, James Bottomley wrote:
>>> And again, why not just fix the userspace tools? That is trivial to do
>>> so and again, could have been done by now in the years this has been
>>> discussed.
>>
>> So I can summarise where I think we are in these discussions:
>>
>> We provide the ability to give all kernel devices a "preferred name".
>> By default this will be the device name the kernel would have originally
>> assigned. the dev_printk's will use the preferred name, and it will be
>> modifiable from user space. All the kernel will do is print out
>> whatever it is ... no guarantees of uniqueness or specific format will
>> be made. Since we're only providing one preferred_name file, the kernel
>> can only have one preferred name for a device at any given time
>> (although it is modifiable on the fly as many times as the user
>> chooses).
>>
>> The design is to use this preferred name to implement what Hitachi wants
>> in terms of persistent name, but we don't really care.
>>
>> All userspace naming will be taken care of by the usual udev rules, so
>> for disks, something like /dev/disk/by-preferred/<fred> which would be
>> the usual symbolic link.
>
> No, udev can not create such a link after the preferred name is set, as
> it has no way of knowing that the name was set.
>
>> This will ensure that kernel output and udev input are consistent. It
>> will still require that user space utilities which derive a name for a
>> device will need modifying to print out the preferred name.
>
> It also doesn't solve the issue of userspace wanting to use such a
> "preferred" name in the command line of tools, as there will not be a
> link back to the "kernel" name directly in /dev/.
Right, this series just add a preferred name interface, and changes
a part of kernel messages.
> So as userspace tools will still need to be fixed, I don't see how
> adding a kernel file for this is going to help any. Well, a bit in that
> the kernel log files will look "different", but again, that really isn't
> a problem that userspace couldn't also solve with no kernel changes
> needed.
hmm, He didnt say "this can solve all problems". I think
preferred name is just a starting point to solve these problems.
Actually, he decided to fix those user space tools to accept
persistent symbolic links, and to show it in outputs.
It's not complete, but a good starting point, isn't it?
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
next prev parent reply other threads:[~2011-06-17 3:33 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
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 [this message]
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=4DFACAF1.3010300@hitachi.com \
--to=masami.hiramatsu.pt@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=nao.nishijima.xt@hitachi.com \
--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