linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Milan Broz <mbroz@redhat.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: Udev integration for device-mapper and its subsystems.
Date: Tue, 28 Apr 2009 21:16:37 +0000	[thread overview]
Message-ID: <49F77235.4060507@redhat.com> (raw)
In-Reply-To: <49F5DC36.9080309@redhat.com>

Kay Sievers wrote:
> On Tue, Apr 28, 2009 at 20:45, Alasdair G Kergon <agk@redhat.com> wrote:
>> The /dev/dm-* devices have been a support headache for us.  I don't know
>> how they first sneaked into some distros but I maintain that dm-* are
>> internal kernel names only of use for debugging purposes and the average
>> sysadmin should never have to encounter them.  If I had my way they
>> would never have become visible to userspace.  (Unfortunately the size
>> restriction on the field prevents us from replacing them with our
>> preferred names within the kernel, unless that's changed since
>> I last looked.)
> 
> There is no size limit anymore.

I think that limit comes from 16 chars for block device name
in register_blkdev() in kernel.
And also DISK_NAME_LEN is 32 (for genhd->disk_name, used by bdevname())...

(The dm device name has limit 128. How to set internal kernel name
to properly to match dm name?)

(And DM device name is already in  /sys/block/<dm-X>/dm/name,
udev rules can use that value for symlink, no timing problem here.)


>> Alternatively, we could see about making dm uuids mandatory and
>> go for something like /dev/dm-<uuid>.

This will break many userspace applications... If the uuid is set,
userspace must use that uuid in all dm-ioctl calls to address device.
And not all users of device mapper library set UUID, because it is
not mandatory (an example is cryptsetup).
(So it is not quick switch because of need to fix all applications to work
properly and set uuid for all dm devices... IMHO)

Milan
--
mbroz@redhat.com

  parent reply	other threads:[~2009-04-28 21:16 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 [this message]
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
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=49F77235.4060507@redhat.com \
    --to=mbroz@redhat.com \
    --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).