Re: Udev integration for device-mapper and its subsystems.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Milan Broz wrote:
> Kay Sievers wrote:
>> On Wed, Apr 29, 2009 at 04:45, Alasdair G Kergon <agk@xxxxxxxxxx> 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@xxxxxxx			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel]     [Linux DVB]     [Asterisk Internet PBX]     [DCCP]     [Netdev]     [X.org]     [Util Linux NG]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux