All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] renaming of device
Date: Thu, 14 Jan 2010 22:42:57 +0100	[thread overview]
Message-ID: <20100114214257.GB23608@tansi.org> (raw)
In-Reply-To: <4B4F600A.7090107@whgl.uni-frankfurt.de>

Hi Sven,

On Thu, Jan 14, 2010 at 07:18:50PM +0100, Sven Eschenberg wrote:
> Hi Arno,
>
> Agreed.
>
> Concerning the actual problem: This should not go into cryptsetup, it's  
> not the right place. 

Well, it is actually already in there, just at the moment it 
gives you the first it finds. I think it is acceptable to have
it in there, as cryptsetup already is a frontend. Writing a 
frontend for a frontend is a bit redundant.

> If we talk convetions, then the convention is:  
> There is only ONE inode representing the device under /dev. If your  
> hotplug manager (and it's configuration) creates multiple such entries,  
> it is an indication for misconfiguration (imho). I.E.: Each device  
> should have one physical identification (the inode carrying major:minor,  
> together with the pathname) and as many logical names (via softlinks) as  
> wanted. This guarantees that the right pathname can be found (not only  
> for dmcrypt btw) and the device is yet useable via it's symbolic names  
> (i.e. UUIDs, volume labels etc.).
>
> If the preference of the system administrator is on UUID names, then  
> those should be created as device files, and the 'traditional names' as  
> softlinks. If yet there is a need to know all device names that link to  
> a certain major:minor, then this can and should be done in a simple  
> shell script, where it belongs in my opinion.
>
> Just my 2 cents

I agree to that. It came when I added udev to my system, which
I do not like, and it creating devices under /dev/scsi/ is the
default under Debian. Clearly this has not been thought through.
As such broken configs can happen and it seems easily, it seems
they need to be expected. 

Arno




> Regards
>
> -Sven
>
>
>
> Arno Wagner schrieb:
>> Well, I think listing all in /dev/ would be an improvement to
>> the current behaviour. Of course people can put their device
>> spceials somewhere else, but that is a pretty big break of
>> convention that IMO does not need to be supported.
>>
>> Arno
>>
>> On Wed, Jan 13, 2010 at 05:18:27PM +0100, Sven Eschenberg wrote:
>>> Hi Arno,
>>>
>>> Indeed cryyptsetup traverses /dev stating each file for major:minor 
>>> and  stops on the first match - at least a trace suggests this. The 
>>> question  is though, if this is an appropriated approach. One thing 
>>> that annoys me   when doing this: There's no guarantee that device 
>>> inodes are in /dev,  nor links to it. In theory it cann be any place 
>>> in the filesystem. there  can be as many links as you want and as 
>>> many inodes for the same device,  as you want.
>>>
>>> Regards
>>>
>>> -Sven
>>>
>>>
>>> Arno Wagner schrieb:
>>>> Having had a bit of time to think about it, it seems that
>>>> it would indeed be necessary to store the device name.
>>>>
>>>> A possible alternative is to traverse all of /dev/ and
>>>> report all devices that match major/minor. This may be
>>>> the solution causing the least effort, as cryptsetup
>>>> is doing something like it already, just that it currently
>>>> stops after the first match.
>>>>
>>>> In fact, I think I prefer for it to report all devices
>>>> that match. 
>>>>
>>>> Arno
>>>>
>>>>
>>>> On Wed, Jan 13, 2010 at 11:20:36AM +0100, Sven Eschenberg wrote:
>>>>> Hi Luca,
>>>>>
>>>>> I doubt this is possible. The only possible thing would be: Modify DM,
>>>>> when a device name is passed in, to keep the passed in name alongside
>>>>> the actual major:minor and provide an IOCTL, to access the information.
>>>>>
>>>>> Regards
>>>>>
>>>>> -Sven
>>>>>
>>>>>
>>>>> On Wed, 2010-01-13 at 08:01 +0100, Luca Berra wrote:
>>>>>> On Sun, Jan 10, 2010 at 09:33:13PM +0100, Milan Broz wrote:
>>>>>>> The algorithm is very simple (and was probably written before
>>>>>>> udev was used so these special links in /dev did not exist).
>>>>>>>
>>>>>>> So it need to add some preferred names and not print the first entry.
>>>>>>>
>>>>>>> Please can you add an issue to project pages to not forget about this?
>>>>>>> Probably good idea to fix it in next minor release.
>>>>>> it could be useful to have the functionality in device-mapper itself,
>>>>>> instead of duplicating in dm-crypt, lvm, dmraid, whatever ?
>>>>>>
>>>>>> Regards,
>>>>>> L.
>>>>>>
>>>>> _______________________________________________
>>>>> dm-crypt mailing list
>>>>> dm-crypt@saout.de
>>>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>>>
>>> _______________________________________________
>>> dm-crypt mailing list
>>> dm-crypt@saout.de
>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>
>>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

  reply	other threads:[~2010-01-14 21:42 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-10 15:16 [dm-crypt] renaming of device Arno Wagner
2010-01-10 19:49 ` Arno Wagner
2010-01-10 20:33   ` Milan Broz
2010-01-11 16:17     ` Arno Wagner
2010-01-13  7:01     ` Luca Berra
2010-01-13 10:20       ` Sven Eschenberg
2010-01-13 13:13         ` Arno Wagner
2010-01-13 16:18           ` Sven Eschenberg
2010-01-13 17:29             ` Arno Wagner
2010-01-14 18:18               ` Sven Eschenberg
2010-01-14 21:42                 ` Arno Wagner [this message]
2010-01-14 22:16                   ` Sven Eschenberg
2010-01-14 22:46                     ` Arno Wagner
2010-01-15  2:17                       ` Sven Eschenberg
2010-01-15  3:58                         ` Arno Wagner
2010-01-15 11:28                           ` Sven Eschenberg
2010-01-16  0:30                           ` Ross Boylan
2010-01-16  2:46                             ` Arno Wagner
2010-01-16  8:39                               ` Milan Broz
2010-01-16 16:22                                 ` Arno Wagner
2010-01-16 18:52                                 ` Sven Eschenberg
2010-01-18 14:06                                   ` Milan Broz
2010-01-18 14:58                                     ` Sven Eschenberg

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=20100114214257.GB23608@tansi.org \
    --to=arno@wagner.name \
    --cc=dm-crypt@saout.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.