From: Hannes Reinecke <hare@suse.de>
To: linux-hotplug@vger.kernel.org
Subject: Re: Udev integration for device-mapper and its subsystems.
Date: Wed, 29 Apr 2009 12:59:56 +0000 [thread overview]
Message-ID: <49F84F4C.10709@suse.de> (raw)
In-Reply-To: <49F5DC36.9080309@redhat.com>
Milan Broz wrote:
> Kay Sievers wrote:
>> On Wed, Apr 29, 2009 at 04:45, Alasdair G Kergon <agk@redhat.com> wrote:
>>>> Also DM allows pretty stupid free-text device names, and names
>>> We took the view there was no need for any restrictions beyond
>>> '/' in the kernel and it was a matter for userspace to choose
>>> the namespace.
>> And these days are over. /dev is not the thing anymore where everybody
>> can mess around.
>
> We had problems with some multipath vendors which named storage device
> paths using strange names/chars (according to LUN name, from hw).
>
> Also dmraid sets uses names collected from proprietary metadata.
>
> Change this means change to several tools. And there are probably still
> reasons to name devices according to hw provided names.
>
> So if there is name limitation, we need to create some mapping which
> is acceptable both for udev and administrators/users...
>
It's not a matter of the name limitation, it's a matter of the
kernel device naming policy.
Every kernel device is named <prefix><iterator>.
Full stop.
I really would think twice before changing this.
But back to the real discussion:
From what I've glanced here is that you're trying to solve
the eternal device mapping question (yet again):
Which device (as logged in /var/log/messages) corresponds
to which logical device as seen by the internal tools.
And similar I thought that this question was shoved over
to userspace/sysadmin, as the in-kernel device names are
strictly speaking valid for the running instance _only_.
Even a reboot might trigger a different mapping scheme.
And anybody really caring about this will have some sort
of syslog managing tool, which then can easily be fed
with the appropriate naming table.
And we had this discussion over and over again on the
scsi mailing list (just look for 'stable device naming')
and the consensus was that in-kernel device naming is
_not_ stable and we should not try to make it so.
I would strongly suspect the same argument holds here, too.
You're heading to a flamewar if you try to implement
some in-kernel stable device naming.
Where is the problem with just having the 'dm-X' as
real device nodes and everything undev /dev/mapper
as symlinks to that?
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
next prev parent reply other threads:[~2009-04-29 12:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-27 16:24 Udev integration for device-mapper and its subsystems Peter Rajnoha
2009-04-28 17:41 ` Kay Sievers
2009-04-28 18:45 ` Alasdair G Kergon
2009-04-28 19:24 ` Kay Sievers
2009-04-28 21:16 ` Milan Broz
2009-04-28 21:25 ` Kay Sievers
2009-04-29 0:28 ` Alasdair G Kergon
2009-04-29 1:16 ` Kay Sievers
2009-04-29 2:45 ` Alasdair G Kergon
2009-04-29 10:05 ` Kay Sievers
2009-04-29 11:52 ` Milan Broz
2009-04-29 12:41 ` Karel Zak
2009-04-29 12:55 ` Kay Sievers
2009-04-29 12:59 ` Hannes Reinecke [this message]
2009-04-29 13:45 ` Kay Sievers
2009-04-29 20:11 ` Peter Rajnoha
2009-04-29 20:46 ` Kay Sievers
2009-04-29 21:44 ` Peter Rajnoha
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=49F84F4C.10709@suse.de \
--to=hare@suse.de \
--cc=linux-hotplug@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).