lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Sun, 05 Nov 2006 19:38:08 +0300
From:	Michael Tokarev <mjt@....msk.ru>
To:	Oliver Neukum <oliver@...kum.org>
CC:	Arjan van de Ven <arjan@...radead.org>,
	Jan Engelhardt <jengelh@...ux01.gwdg.de>, andrew@...rond.org,
	linux-kernel@...r.kernel.org
Subject: Re: Scsi cdrom naming confusion; sr or scd?

Oliver Neukum wrote:
> Am Sonntag, 5. November 2006 15:06 schrieb Arjan van de Ven:
>> and this is why it's wrong to make naming policy a kernel thing!
>> Userspace is the right place to do this (and there I suspect the name
>> will end up being /dev/cdrom)...... the kernel really shouldn't care at
>> all what the name is.
> 
> I have to disagree. This precisely shows that the reverse is true.
> This way the chance of having a default name guaranteed to work
> is lost. If you want an alternate name, use a symlink.

Yes, YES.  That's what I always tried to say during similar discussions.

In additional to the "default name" (which is, strictly speaking, is NOT
"default" in many cases, such as when you have USB drives connected or
not and all the sdX and srY renumbering, but that's different story, and
many devices are still has "default name"), there's another reason: kernel
should name the devices *somehow*, and it'd better the name exists in /dev.
Think /proc/partitions for example -- I don't damn want to see device numbers
(major+minor) in there, and all the tools searching the whole /dev to find
the device node for it.  By the way, lilo breaks if it can't find device
nodes in /dev listed in /proc/partitions, and I can't blame it.

/mjt
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ