Cset 1.1490.4.201 - dasd naming

Cset 1.1490.4.201 - dasd naming

[Pete Zaitcev]

Hi, Martin:

In a recent changeset in Linus' tree, there's your diff which blows up
the dasd naming scheme, with the comment:
 - 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?

-- Pete

P.S. Cset
http://linux.bkbits.net:8080/linux-2.5/cset@1.1490.4.201?nav=index.html|src/|src/drivers|src/drivers/s390|src/drivers/s390/block|related/drivers/s390/block/dasd_genhd.c

Re: Cset 1.1490.4.201 - dasd naming

[Martin Schwidefsky]

Hi Pete,

> In a recent changeset in Linus' tree, there's your diff which blows up
> the dasd naming scheme, with the comment:
>  - Change dasd names from "dasdx" to "dasd_<busid>_".
We plan to do this for tape and other ccw devices as well (where applicable).

> 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.

blue skies,
   Martin

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com

linux-2.6.1 x86_64 : STACK_TOP and text/data

[dada1]

Hi all

Anybody knows why STACK_TOP is defined to 0xc0000000 in x86_64 ?

This means that stack allocated variables are all in the first 4GB 
quadrant in memory.
As the default virtual addresses of text/data of a programm are in this 
same quadrant, some programming errors could be undetected.
(Some programmers could still cast some pointers to 'unsigned int' for 
example, and this could 'work')

Tru64 has a different strategy :
Program text starts at 0x120000000
Program data starts at 0x140000000
Stack is just under text, but still not in the first 4GB quadrant.

This way, programmers errors are likely to be detected at dev time.

Another point is that BSS zone (heap) cannot exceed 3GB in x86_64 mode, 
since the brk hit the stack.
libc malloc then fallback to use a lot of arenas... suboptimal in terms 
of  vmas.

Strangely, in ia32 emulation mode, the stack is placed at the 4GB limit !

Thank you
Eric Dumazet

Re: Cset 1.1490.4.201 - dasd naming

[Pete Zaitcev]

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

Re: Cset 1.1490.4.201 - dasd naming

[Martin Schwidefsky]

Hi Pete,

> 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).
The idea was to get rid of the dasdxyz names which are not intuitive.

> 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.
Ok.

> 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.
That is probably the main argument to go back to the old names. After
udev and friends are in place it is not important how the disk is named
internally. The only place where it would surface is on the root=
parameter.

I'll discuss this with the Horst again to see if we really need the
dasd_<busid>_ names or if we can live with the old style names on the
root= parameter.

blue skies,
   Martin

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com

Re: Cset 1.1490.4.201 - dasd naming

[Arnd Bergmann]

> That is probably the main argument to go back to the old names. After
> udev and friends are in place it is not important how the disk is named
> internally. The only place where it would surface is on the root=
> parameter.

Even for root=, it probably does not matter as long as udev is used
in the initrd/initramfs. The main argument against the new naming is
that udev can trivially create these or other persistent names, while
it's very hard for udev to calculate the compatible names.

        Arnd <><

Re: Cset 1.1490.4.201 - dasd naming

[Martin Schwidefsky]

Hi Pete,

> > 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.
> That is probably the main argument to go back to the old names. After
> udev and friends are in place it is not important how the disk is named
> internally. The only place where it would surface is on the root=
> parameter.
>
> I'll discuss this with the Horst again to see if we really need the
> dasd_<busid>_ names or if we can live with the old style names on the
> root= parameter.

We discussed udev and friends today again and we decided to go back to
the old dasdxyz names. You'll send the patch with the next update to
Andrew.

blue skies,
   Martin

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com