mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jon Masters <jonathan@jonmasters.org>
To: Nao Nishijima <nao.nishijima.xt@hitachi.com>
Cc: gregkh@suse.de, James.Bottomley@suse.de, rwheeler@redhat.com,
	linux-kernel@vger.kernel.org,
	linux-hotplug-devel@lists.sourceforge.net,
	linux-hotplug@vger.kernel.org, masami.hiramatsu.pt@hitachi.com,
	mdomsch@dell.com
Subject: Re: [RFD] Device Renaming Mechanism
Date: Tue, 02 Nov 2010 03:00:08 -0400	[thread overview]
Message-ID: <1288681208.3916.170.camel@constitution.bos.jonmasters.org> (raw)
In-Reply-To: <4CAEAAD4.2080504@hitachi.com>

On Fri, 2010-10-08 at 14:23 +0900, Nao Nishijima wrote:

> I'm trying to solve a device name(or device node) mismatch problem caused by
> device configuration changes. Now I have an idea of device renaming to solve it,
> and would like to request for comments from kernel developers.

I apologize that I missed this mail until I was doing some podcasts ;)

Although not necessarily useful for within-device volumes, I would
nonetheless like to call attention to the DMTF SMBIOS specification, and
in particular structure Type 9, which allows system vendors to provide
various information about the correct mappings of physical system slots
to devices. Matt Domsch produced a utility a while back called
biosdevname that can be used to implement one possible device renaming
mechanism for network interfaces, based on the system slot identifier,
but of course there is no reason not to support the other devices.

I have read the other mails, but I would love to know what Greg and Kay
think about supporting automatic renaming in the case where the system
*actually told you the preferred name* in such a table. Perhaps we can
discuss this in Cambridge this week.

Jon.



  parent reply	other threads:[~2010-11-02  6:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-08  5:23 Nao Nishijima
2010-10-08 20:48 ` Greg KH
2010-10-18 11:43   ` Nao Nishijima
2010-10-18 12:33     ` Kay Sievers
2010-10-25 10:55       ` Nao Nishijima
2010-11-02  7:00 ` Jon Masters [this message]
2010-11-02 11:14   ` Greg KH

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=1288681208.3916.170.camel@constitution.bos.jonmasters.org \
    --to=jonathan@jonmasters.org \
    --cc=James.Bottomley@suse.de \
    --cc=gregkh@suse.de \
    --cc=linux-hotplug-devel@lists.sourceforge.net \
    --cc=linux-hotplug@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mdomsch@dell.com \
    --cc=nao.nishijima.xt@hitachi.com \
    --cc=rwheeler@redhat.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

all inboxes | Powered by JetHome®