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-next>] [day] [month] [year] [list]
Date:	Wed, 15 Jun 2011 17:16:10 +0900
From:	Nao Nishijima <nao.nishijima.xt@...achi.com>
To:	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:	James.Bottomley@...senPartnership.com, greg@...ah.com,
	kay.sievers@...y.org, jcm@...hat.com, hare@...e.de,
	stefanr@...6.in-berlin.de, yrl.pp-manager.tt@...achi.com
Subject: [PATCH 0/3] [RFC] Persistent device name using preferred name

Hi,

This patch series provides preferred name into kernel and procfs
messages. Preferred name is user's preferred name for a device.

The purpose of this feature is to solve the persistent device
naming issues which was discussed here:

 http://marc.info/?l=linux-scsi&m=130200794615884&w=2

There are four issues.
1. kernel messages doesn't show persistent device names
2. procfs messages doesn't show persistent device names
3. Some commands didn't support persistent device name in arguments
4. Some commands message didn't show persistent device names

Then I suggested the intermediate device naming which changes
the naming scheme, but it was rejected. I realized that we should
use udev to provide persistent device names instead of change the
naming scheme.

In LKML discussion, a new idea was suggested by James Bottomley.
This idea allows kernel messages show preferred names by adding a
new attribute to a device, kernel messages show this new attribute.
This idea's advantage is not to change the current naming scheme.

I tried implementation of preferred name, and then there are two
discussion points.

(a) Which devices need support?
Preferred name is stored in struct device. Therefore it is available
for all devices if we make preferred name support with other device
types.

This patch series only support scsi block device. Is there the device
which needs support? (e.g. Ntwork devices, generic SCSI devices, etc.)

(b) What kind of procfs form is good?
I implemented preferred name something like this,

(preferred name assigned foo to sda)
#cat /proc/partitions
major minor  #blocks  name

   8        0  488386584 foo
   8        1     194560 foo1
...

Do you needs device name filed?
Something like this,

(preferred name assigned foo to sda)
#cat /proc/partitions
major minor  #blocks  name preferred

   8        0  488386584 sda foo
   8        1     194560 sda1 foo1
...


Issue 3 and 4 is command releated issue. Commands have to be
modified to use preferred name. We need to create library for
preferred name.

Our goal is to solve those issues, and users can use and see
preferred name anywhere.

TODO:
- To change kernel messages
  I'm going to change a device name to a preferred name by
  dev_name() in mmc, blk-core, sg, sr, st, fs, etc.

I would welcome any thoughts, comments and suggestions.

Thanks,

---

Nao Nishijima (3):
      [RFC] fs: print preferred name in procfs messages
      [RFC] sd: print preferred name in kernel messages.
      [RFC] genhd: add a new attribute in device structure


 block/genhd.c              |   28 ++++++++++++++++++++++++++++
 drivers/scsi/sd.c          |    2 +-
 drivers/scsi/sd.h          |    2 +-
 fs/partitions/check.c      |    8 +++++---
 include/linux/device.h     |    9 +++++++++
 include/scsi/scsi_device.h |    2 +-
 6 files changed, 45 insertions(+), 6 deletions(-)

--
Nao Nishijima (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