> To be honest: that is not very likely. Especially not in > this case. > Suppose we push them all upstream and only one upstream > actually picks it > up and we implement that. That would still leave us > nowhere...
I see what you mean. It's double or nothing. Without mke2fs support for respecting the RECOMP area (and mkreiserfs, and all other supported file systems), support for IPLing zipl from a CMS minidisk is a moot point. zipl will never see a RECOMP area because mke2fs (or whatever) wiped it out when the file system was created. > I'm afraid that partman is _very_ Debian specific and > you're basically > talking to the upstream (the team behind debian-boot > mailing list). OK. Well, support for recognizing the implicit partition of a CMS minidisk is independent of respecting a RECOMP area. Those are two separate issues. The former is a deficiency in the installer. The latter is an enhancement request. As it stands today, the Debian installer cannot install Debian GNU/Linux to CMS minidisks, period. As far as GNU/Linux itself is concerned, the only part of the filesystem which cannot be on a CMS minidisk is the /boot directory. All other parts of the filesystem and all swap partitions can be on CMS minidisks. But the Debian installer cannot currently handle them. I currently have a Debian GNU/Linux system running in a virtual machine under z/VM that uses CMS minidisks. But I had to install to cdl disks and then use the installer as a "rescue floppy" to copy the data to CMS minidisks. Another problem is that the dasd_mod driver does not automatically bring CMS minidisks on-line. I had to create a file called dasd in /etc/modprobe.d to supply options to dasd_mod to bring these minidisks online at IPL time. (And then I had to run update-initramfs and zipl.) It worked. But figuring out what to do and how to do it was not trivial. And of course, there is nothing in the install manual about this. I would hardly call this a user-friendly install. Further complicating matters was my desire to use the dasd_diag_mod module to do the I/O, which did not exist in the stock kernel for etch. I had to download the kernel source package and create a custom kernel in order to use dasd_diag_mod. (And then I had to update /etc/modprobe.d/dasd again to tell dasd_mod to use dasd_diag_mod for all the CMS minidisks, and then I had to run update-initramfs and zipl again.) Fortunately, it appears that the 2.6.24 stock kernel for lenny now includes this module. :-) It is possible to get it working. But when it comes to CMS minidisks, Debian for s390 is definitely a hacker's distro only. > > For what it's worth, the S390 Linux community is a > > vibrant one. > > Great. Question is how to translate that into active > involvement in the > Debian s390 port. Ah, yes. That is the question. I think there would be more involvement (from the development and support perspective) in the Debian s390 port if there were more System z shops using the Debian s390 port. Similarly, there would be more System z shops using the Debian s390 port if it were better supported. As you yourself have admitted, support for this port is pretty thin. In many ways this is a "Which came first, the chicken or the egg?" scenario. But if it is so difficult to install in an optimal way for a z/VM guest, that is a barrier to wider use. This is going to be a rather long reply. Sorry. But you asked. Let's look at this from IBM's perspective. IBM spent a fortune in the 1990s trying to promote their i386 operating system -- OS/2 -- and lost. They not only lost the desktop (and server) war, they also lost a lot of money. IBM likes Linux because they don't have to spend much money on development and support costs. They don't own it or control it. But then again, neither does Microsoft. :-) On the mainframe platform, they make money with Linux primarily by (a) selling more mainframe hardware to support Linux and (b) by selling software licenses for proprietary software that runs on Linux, such as DB2. They want the Linux community to support their hardware. But they want to keep their support costs down. The more Linux distributions they have to support, the higher their support costs. So they pick a couple of distros to support and ignore the rest. Significantly, they picked two distros that both use rpm-format packages. Here's an example. As I said earlier, I am a z/VM systems programmer at an IBM mainframe shop. I'm getting ready to install z/VM 5.3. One of the enhancements to z/VM 5.3 is that TCP/IP now supports SSL/TLS for its FTP client and FTP server. (I'm talking here about the FTP client and FTP server that run under the CMS operating system.) For some reason, they decided to implement the SSL encryption and decryption in a separate service machine which runs Linux. (I suppose it was cheaper than porting the entire SSL support infrastructure to CMS.) That's an opportunity right there. But then they go on to say that only Suse and Red Hat are supported. Here's the link: http://www.vm.ibm.com/related/tcpip/tcsl530.html And even if you elect to go with an unsupported distro, the software packages that they provide are in rpm format only. It appears that source packages are available. But the source packages are also in rpm format only. To run this under Debian, do you realize the hoops I would have to go through? I would have to have, say, a Suse distribution installed, download the source rpm package to the Suse distribution, install it, somehow export the sources via a portable format (a .tar file maybe), import the .tar file to a Debian system, unpack it, somehow convert it to a Debian source package, then convert the Debian source package to a Debian binary package. And when I get all done, if I have any problems, it's unsupported. Do you begin to see the hurdles I face? And I like Debian. And I want to use Debian. But even for me, do I really want to do this? Do I even know how to do this? If someone who knows how to do this stuff would create a Debian package for vmssld, that would be a step in the right direction. Somehow, you've got to persuade IBM to support Debian. And if they think it will increase their sales enough to make it worth their while, they will. The above is just one example. Here's another example. Here's a link to the support requirements for DB2: http://www.ibm.com/developerworks/wikis/display/im/DB2+9.5+for+Linux+-+Supported+Environments Again, notice that Red Hat and Suse are the only s390 distributions supported. Also notice that they want s390x, not s390. In other words, they want you to use a 64-bit kernel. But ... there is a window of opportunity here. Notice that Ubuntu is supported! It is not supported on the s390x platform: it is only supported on the x86 and x86_64 platforms. But it is supported! And since Ubuntu uses the Debian package management system, that means that, at least for this product, they have already broken the Debian package management barrier! If they support the s390x platform and the Debian package management format, it won't take much additional effort to support the Debian package management format for the s390x platform. Push, somebody! Now let's look at it from the perspective of the Debian development community. Unlike Red Hat, Suse, and other commercial distributions, Debian is developed and maintained primarily by individuals. For architectures such as i386, chances are the developer already owns an Intel (or compatible) box. What he develops he can directly benefit from himself. Necessity is the mother of invention. A developer will normally develop software for free only if it benefits himself. Not too many individuals have a mainframe sitting around in their basement. One can create a mock mainframe with Hercules. But IBM won't license modern versions of z/VM to run under Hercules, except possibly by special bid. That might hurt their hardware sales. And I suspect that if you do manage to get a special bid, the price will be so high and performance will be so poor (due to the overhead of the Hercules emulation) that you might as well buy an entry-level mainframe. So there you go. So what individuals would have the incentive to develop and support mainframe software for free? People like me -- system programmers and application programmers who work on a mainframe and have some kind of a need for it. The trouble is, most of us don't have the requisite skills to do Linux development. Most of us old mainframers don't know C. Or shell scripts. Or perl or awk. Etc. Retired mainframers who have lots of time on their hands and the initiative to learn these new skill sets are probably the best people to recruit for development and support. The people who still work for a living can assist in testing, maybe, but probably don't have time to learn the skills required for development. Now let's look at it from a management point of view. Linux on System z is normally implemented in production situations for server consolidation. That means big business. An outage can cost millions of dollars. Those people want someone to call when things go wrong. They want a support contract. Since Debian doesn't offer paid support contracts, even for the ubiquitous i386 platform, that means persuading a third party company to offer Debian for s390 support. A couple of years ago, someone was able to persuade Hewlett-Packard to support Debian on some of its servers. http://www.infoworld.com/article/06/08/14/HNhpsupportdebian_1.html That's the kind of thing we need on the mainframe. I know that, at least at one time, Sine Nomine Associates (http://www.sinenomine.net) offered paid third party support for Debian GNU/Linux on the s390 platform, subject to some terms and conditions. (This is not an endorsement and I have no financial or personal interest in Sine Nomine Associates!) I don't know if they still do that, but that's the kind of thing that management wants. And if they are using proprietary licensed software, such as DB2, they want the distro to be supported by the vendor as well. That's my two cents worth. Some of these things you do not control. Some of them you do. Start with what you do control. Make your s390 installer usable for CMS minidisks. That's a start. Port the vmssld package to Debian for s390. I will do what I can to help you in testing, etc. Both of us can pester IBM for Debian support for licensed software. Try to persuade companies like Sine Nomine to offer or advertise third-party support for Debian for s390. Try to recruit retired mainframers to work on the port. Offer education and training to us old guys for Linux skills. Maybe you can pair a retired mainframer with a high school / college kid in the "Google summer of code" program in a symbiotic relationship. The kid will learn mainframe skills. The old guy will learn Linux skills. Both will benefit. Cheers, Steve Powell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
