public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pete Zaitcev <zaitcev@redhat.com>
To: "Martin Schwidefsky" <schwidefsky@de.ibm.com>
Cc: laroche@redhat.com, linux-kernel@vger.kernel.org, zaitcev@redhat.com
Subject: Re: Cset 1.1490.4.201 - dasd naming
Date: Wed, 28 Jan 2004 10:05:07 -0800	[thread overview]
Message-ID: <20040128100507.7b3dfeed.zaitcev@redhat.com> (raw)
In-Reply-To: <OFCE30A640.024A04A1-ONC1256E28.003023EA-C1256E28.0030BF4E@de.ibm.com>

On Tue, 27 Jan 2004 09:52:27 +0100
"Martin Schwidefsky" <schwidefsky@de.ibm.com> wrote:

> >  - Change dasd names from "dasdx" to "dasd_<busid>_".

> > This breaks mkinitrd, nash, and mount by label (not to mention every
> > zipl.conf out there, because root= aliases to /sys/block/%s).
> > Would you please explain what exactly you were thinking when you
> > submitted that patch?

> The reason for this change is the requirement to have persistent device
> names. The /dev/dasdxyz naming schema heavily depends on the order in
> which the device are added. Not good for persistent names. This change
> affects four things: 1) the internal name, 2) the name of the sysfs
> directory, 3) the root= parameter and 4) the hotplug events for dasd
> devices.

Martin, it is your architecture to break as you wish, but my gut feeling
is that you'd never get away with this if you did it on anything using
common use peripherals. This is a return to times of UNIX v6 and /dev/rk1a.
The chief penguin repeatedly stated that he wanted to see /dev/diskN
or similar (defined by a userland policy).

Considering Fedora Core 2, I do not know if we have time to repair the
damage. For the moment, I am patching a reverse patch.

Running a statically built dasd and having root=/dev/dasd_0.0.0202_1
in zipl.conf works fine. I am considering if we can get away with just
that and fixing mount by label to work. It's not the end of the world,
but it's annoying.

Is there a story of a real world deployment where the 2.4 scheme was
a hindrance which you could share? Honestly, I'm surprised you bring
the matter of "persistent names" instead of, say, exhaustion of
address range and majors.

-- Pete

  parent reply	other threads:[~2004-01-28 18:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-27  8:52 Cset 1.1490.4.201 - dasd naming Martin Schwidefsky
2004-01-27  9:25 ` linux-2.6.1 x86_64 : STACK_TOP and text/data dada1
2004-01-28 18:05 ` Pete Zaitcev [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-01-29 18:27 Cset 1.1490.4.201 - dasd naming Martin Schwidefsky
2004-01-28 19:10 Arnd Bergmann
2004-01-28 18:25 Martin Schwidefsky
2004-01-26 23:23 Pete Zaitcev

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=20040128100507.7b3dfeed.zaitcev@redhat.com \
    --to=zaitcev@redhat.com \
    --cc=laroche@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    /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