[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1288681208.3916.170.camel@constitution.bos.jonmasters.org>
Date: Tue, 02 Nov 2010 03:00:08 -0400
From: Jon Masters <jonathan@...masters.org>
To: Nao Nishijima <nao.nishijima.xt@...achi.com>
Cc: gregkh@...e.de, James.Bottomley@...e.de, rwheeler@...hat.com,
linux-kernel@...r.kernel.org,
linux-hotplug-devel@...ts.sourceforge.net,
linux-hotplug@...r.kernel.org, masami.hiramatsu.pt@...achi.com,
mdomsch@...l.com
Subject: Re: [RFD] Device Renaming Mechanism
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists