FYI, I've finally pushed Stephen Powell's s390 changes.
I wanted to add tests, but never found the time.
They would have been too involved, for not enough value,
since they'd be runnable only with relatively rare dasd disks.
commit 2d0f3bc1d36268ddaeeb0c1052b5b3a4c76d8503
Author: Jim Meyering <meyer...@redhat.com>
Date: Thu Nov 25 15:57:00 2010 +0100
s390: avoid warnings
* libparted/labels/vtoc.c (vtoc_read_volume_label): Remove decl
of unused var.
* libparted/labels/fdasd.c (fdasd_valid_vtoc_pointer): Return
a value also when successful.
* libparted/labels/dasd.c (dasd_alloc_metadata): Initialize "part"
to NULL solely to avoid a spurious used-uninitialized warning.
commit f85127be13c0a2e896c39c65a50085b334cbadab
Author: Stephen Powell <zlinux...@wowway.com>
Date: Thu Oct 28 18:18:16 2010 +0200
doc: add NEWS entries for s390 fix and improvements
commit db20944f8352f900d0d7eb6d78b367a7049151dd
Author: Stephen Powell <zlinux...@wowway.com>
Date: Thu Oct 28 18:13:07 2010 +0200
s390: make DIAG driver work for FBA DASD with block size > 512
In order to make the DIAG driver work for FBA DASD with a block
size greater than 512, I had to make a rather awkward patch to
C function vtoc_read_volume_label in libparted/labels/vtoc.c.
The "right" logic would be "If this is an FBA DASD device
using the DIAG driver, and the effective block size used by the
DIAG driver is greater than 512, then do it this way. Else,
do it the normal way." (Note that when using the FBA driver,
the effective block size is always 512, regardless of the CMS
logical block size stored in the volume label. The DIAG driver,
on the other hand, honors the CMS logical block size.)
The problem is that the information needed to make that decision
has not been provided to the routine (via the parameter list).
So what I ended up doing is assuming the normal way, then if
I don't find a recognized volume label header (VOL1, LNX1,
or CMS1, in EBCDIC), then I assumed that it must be the special
case. So in the special case I end up doing an unnecessary
read. It's a kludge, but it works.
commit a4ca657a7ad4e19baf3a171f038764c48468e1ea
Author: Jim Meyering <meyer...@redhat.com>
Date: Wed Oct 27 15:16:30 2010 +0200
tests: new script to generate 9-pte-GPT-tables
commit f78e3f074c69ec4450d7f1fa3379da3312968f25
Author: Jim Meyering <meyer...@redhat.com>
Date: Mon Oct 25 21:44:31 2010 +0200
cleanup: use verify, not PED_ASSERT to check struct sizes
* libparted/labels/gpt.c: Use compile-time "verify" rather than
run-time PED_ASSERT to ensure struct sizes are as expected.
commit 2e9383d725482188e47f35df368604a813ea16f8
Author: Stephen Powell <zlinux...@wowway.com>
Date: Sat May 8 09:39:24 2010 +0200
s390: improve/correct DASD support
The long title would be "corrections to partition size and location
calculations for type 1 partitions for s390 dasd".
This could be treated as two separate fixes, one to make corrections
for LDL formatted disks and one to add support for CMS formatted
disks. I see CMS formatted disks as a variant of LDL formatted
disks, with the additional twist that CMS formatted disks can
be reserved or recomped, which LDL formatted disks cannot be.
This affects the size and location of the partition.
With these patches, parted matches the behavior of the Linux kernel
in recognizing partitions on CMS- and LDL-formatted disks, as documented
in the Linux kernel source code in routine fs/partitions/ibm.c.
Calculation of the metadata has also been changed so that parted will
show no free space on such a disk. In some cases there are now two
non-contiguous metadata extents: one at the beginning of the disk and
one at the end.
As before, parted only supports CKD DASD using the ECKD driver.
FBA DASD and CKD DASD using the DIAG driver are still not supported.
In my regression testing I have discovered some problems in the area
of recognizing file system options. However, since I can duplicate
these errors on a version of parted which does not contain my changes,
I have concluded that my changes did not cause this and therefore
this is an unrelated bug.
_______________________________________________
bug-parted mailing list
bug-parted@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-parted
