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] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E1FE446.4040208@hitachi.com>
Date:	Fri, 15 Jul 2011 15:55:02 +0900
From:	Nao Nishijima <nao.nishijima.xt@...achi.com>
To:	Karel Zak <kzak@...hat.com>
Cc:	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	James.Bottomley@...senPartnership.com, kay.sievers@...y.org,
	jcm@...hat.com, greg@...ah.com, dle-develop@...ts.sourceforge.net,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	yrl.pp-manager.tt@...achi.com, dgilbert@...erlog.com,
	stefanr@...6.in-berlin.de, hare@...e.de
Subject: Re: [RFC PATCH 0/4] Persistent device name using alias name

Hi, karel

(2011/07/09 4:45), Karel Zak wrote:
> On Fri, Jul 08, 2011 at 05:45:47PM +0900, Nao Nishijima wrote:
>> This patch series provides an "alias name" of the disk into kernel and procfs
>> messages. The user can assign a preferred name to an alias name of the device.
>>
>> Based on previous discussion (*), I changed patches as follows
>> - This is "alias name"
>> - An "alias name" is stored in gendisk struct
>> - Add document to Documentation/ABI/testing/sysfs-block
>> - When the user changes an "alias name", kernel notifies udev
>>
>> (*) http://marc.info/?l=linux-scsi&m=130812625531219&w=2
>>
> 
> [...]
> 
>> [localhost]# cat /proc/partitions
>> major minor  #blocks  name
>>
>>    8        0   12582912 foo
>>    8        1   12582878 foo1
>>    8        0    8388608 sdb
>>    8        1     512000 sdb1
>>    8        2    7875584 sdb2
> 
>  If there is not /dev/foo and /sys/block/foo then the patch introduces
>  a REGRESSION. 
>  
>  The names from /proc/partitions are used in many applications
>  (libblkid, fdisk, ...) for many many years. The applications will not
>  work as expected.
> 

I think that it is not a regression when users do not set an alias name.
Of course, I am going to modify all these utils so that users can use
alias names.

The purpose of alias names is to unify the name of device which users
operate and see. Therefore, I think that users would like to get an
alias name from it, because currently they get a device name form it.

However, for who wants to use alias name only for dmesg, I have an
enhancement idea that users can choose alias names or device names in
procfs by sysctl (default is device names).

I would like to hear your opinion about this.

>  It's crazy to assume that all the applications will be improved to
>  translate the "pretty name" from /proc/partitions by /sys/block/<maj>:<min>.
> 
>  Note, it's pretty naive to expect that people will use the pretty
>  names for printk()/dmesg only. I'm absolutely sure that it's will be
>  expected (by end-users) in /etc/fstab, mount, df, fdisk, ...
> 
>  It's will be necessary to modify all these utils. 
> 

Yes, I am going to modify all these utils to support udev persistent
names(including alias name).

I had looked over some commands where those get a device name from.
Most of them get a device name from /proc/partitions, also other
commands get it from /etc/fstab, /sys/block/ or own device database.

I am going to modify those commands to get a device name from /dev/disk.

>  The patch is opening Pandora's box :-(
> 

Best regards,

-- 
Nao NISHIJIMA
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., YOKOHAMA Research  Laboratory
Email: nao.nishijima.xt@...achi.com
--
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