On Sat, 08 May 2010 04:06:16 -0400 (EDT), Jim Meyering wrote: > Stephen Powell wrote: >> As promised earlier today, I now have the following patch files on my >> web site ready for download: >> ... > > I don't often see context diffs, as opposed to unified diffs. > Most people prefer to read the latter. You can generate them with diff -u > if you're using GNU diff, or with git diff if you ever get around > to using git.
Jonathan Nieder explained to me how to make unified diffs in more detail in a private e-mail. Thanks to both you and Jonathan. I apologize for not following the normal conventions. This stuff is all new to me. I'm used to applications programming in an IBM mainframe shop using PL/I. The whole GNU/Linux world is a total paradigm shift for me. The operating system, the programming language, the tools, etc. are all completely new to me. What I do have to offer is basic programming aptitudes and a knowledge of IBM mainframe hardware architecture, especially when running in a virtual machine under z/VM. But everything else is totally different. Please be patient with me as I learn. > > I've confirmed that those patches do apply locally and removed a couple > of trialing spaces so "make syntax-check" still passes. That's another tool I know nothing about. :-( I use front-ends like dpkg-buildpackage, which no doubt use make "under the covers", but I never directly invoke make. > > Once I have confirmation that the FSF has received your paperwork, > I'll review and test. I mailed the paperwork today. I can send you an e-mail with a PDF file attached that has copies of the paperwork, if that will speed things up. > > One way that you can help in the mean time is by writing a slightly > more detailed summary of what changed. For example > * what is it that would fail without your patch, but works with it? > * how does your improvement make things better? > That is the sort of information I'd like to put in NEWS. > Does this count as a bug fix? It seems so, but there's also > the free-space change that looks more like an improvement than a bug fix. > I haven't looked at details yet... Necessity is the mother of invention. What prompted me to look into this in the first place was a desire to install Debian GNU/Linux for s390 onto reserved CMS minidisks in a virtual machine under z/VM. Reserved CMS minidisks are advantageous to use when Linux is run in a virtual machine under z/VM primarily for two reasons: (1) reserved CMS minidisks can be accessed and manipulated read/write by both CMS and the Linux kernel, and (2) reserved CMS minidisks are eligible for use by the DIAG driver, a high-performance disk driver usable only when GNU/Linux is running in a virtual machine under IBM's z/VM operating system. But the Debian installer would not work with CMS minidisks. I opened a wishlist bug report against the Debian installer years ago, but no action ensued until recently. Someone looked into it and said that the reason that the Debian installer didn't work with CMS minidisks is that parted didn't recognize them. So my goal was to enhance parted so that I could install Debian directly to CMS minidisks. (See http://www.wowway.com/~zlinuxman/diag250.htm for the convoluted way I have to go about installing Debian to CMS minidisks due to the lack of CMS minidisk support in parted.) I really didn't feel adequate for the job of changing parted, a program written in C, a language that I don't know. But Debian is a volunteer organization. They don't have the money to go out and buy IBM mainframes, license z/VM, and do their own development and testing. I already had all that, but did not possess C knowledge. It was easier for me to acquire enough C knowledge to make the changes than it was for Debian to acquire a real mainframe and a z/VM license. In the process of making these changes I discovered some bugs in the existing code for LDL disks, to which CMS disks are closely related. Now, for the specific "bullet points" for NEWS: o Fixed a bug in which the starting block for the implicit partition of LDL disks was miscalculated if the disk was formatted at a block size other than 4096. The program now calculates the starting block of the partition correctly, regardless of whether the disk has a block size of 512, 1024, 2048, or 4096. (These are all the valid block sizes.) o Enhanced LDL support to use the "formatted blocks" field of an LDL- format disk label (for version 2 and above LDL formats) to determine the size of the partition, rather than relying on disk geometry. This will allow parted to determine the correct partition size if, for example, an image copy backup of a 3390-3 volume is taken at the home site and restored to a 3390-9 volume at a disaster recovery hot site. The extra space at the end of the 3390-9 volume is not part of the partition, and parted now knows that. o Added support for CMS-formatted minidisks, both non-reserved and reserved, provided that they are on CKD DASD. CMS minidisks on FBA DASD are not supported at this time. Also, CMS minidisks on CKD DASD which use the DIAG driver are not supported either. The ECKD driver must be used. The changes to function dasd_alloc_metadata in dasd.c are necessary to support both the bug fix and the enhancements. It is important that no metadata/partition overlap occurs, and it is important that all sectors on an LDL or CMS disk be covered either by the partition or by metadata. -- .''`. Stephen Powell : :' : `. `'` `- _______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
