Porting FreeBSD to Z mainframes idea

[Cy Schubert]

In message <CANCZdfoUae=ezE=812=w=7UWwvQfk9iknDbN3AkUD3KCA3CFLQ at mail.gmail.c
om>
, Warner Losh writes:
> On Sat, Jan 25, 2020, 3:56 AM Bjoern A. Zeeb <bzeeb-lists at lists.zabbadoz.net>
> wrote:
>
> > On 19 Jan 2020, at 14:21, Shivank Garg wrote:
> >
> > Hi,
> >
> > > On Sun, Jan 19, 2020, 3:56 AM Greg 'groggy' Lehey <grog at freebsd.org>
> > wrote:
> > >
> > >> On Saturday, 18 January 2020 at 12:43:02 +0530, Shivank Garg wrote:
> > >>> Hi!
> > >>> I wish to pursue this idea of porting FreeBSD to IBM Z mainframes.
> > >>> Currently, there are no BSD derivatives for Z mainframes, and I find
> > the
> > >>> idea of porting FreeBSD to Z mainframe.
> > >>>
> > >>> Someone on IRC suggested to port NetBSD first, as it is easier to port
> > on
> > >>> different hardware platforms.
> > >>
> > >> Agreed, at least at first sight.  Have you discussed this on the
> > >> NetBSD lists?
> > >>
> > >
> > > No. I haven't discussed this with them yet.
> >
> > I actually also have no idea about their community thinking about it still.
> > Would be curious to know.
> >
> >
> > >>> There is a sponsored internship program called OpenMainFrame
> > >>> Mentorship. So, I thought to propose this project in this
> > >>> program. But I'm a beginner and have very little idea about the
> > >>> whole porting process and challenges faced during it.  I will be
> > >>> very thankful if you can give suggestions about this, and how much
> > >>> time will it take for a beginner? The mentorship program is for a
> > >>> span of 3-4 months.
> >
> > I think 3-4 months is nowhere near where you can get to anything useful
> > if you have no clue about the mainframe architecture and low-level
> > kernel bringup.
> >
> >
> > >>> Also, If it's too difficult, can there be any doable goals in the
> > >>> porting process that I can propose for the program and I would
> > >>> continue the project even after the program is over. I personally
> > >>> feel the project has good potential, and It will be very helpful in
> > >>> my learning growth.
> >
> > The latter probably, the former not so much.  I’ve been contemplating
> > it on-and-off for more than a decade.
> >
> > I’ve made make buildworld buildkernel work twice already with skeleton
> > (read mostly empty implementation) in order to allow people to join and
> > help.
> >
> > I’ve asked developers and people who did work on other OSes.
> > I’ve never found the really good “YES DO IT” case apart from it being
> > a hobby project.  I’ve found people who were interested in running it.
> > In order to justify it becoming an official FreeBSD platform to run on
> > you need more than a single customer sadly and you probably need someone
> > from the inside at big blue to be able to actually run it on anything
> > that is not qemu (or some open source emulator).
> >
>
> I'm mulling how to have a good round of discussions about the minimums to
> be in the tree. One thing we need is good CI to know things are working.
> For that, qemu is great. In fact, there is a strong desire to have a smoke
> test that makes a bootable image and then boot it to multi user that is
> completely automatic.
>
> But running on real hardware also is needed. It makes the port useful. It
> also increases the appeal and often brings resources to maintain it...

IBM mainframes (360 and its descendants to z/Series) have very little in 
common with the architectures we currently support, i.e. there is no stack, 
I/O is performed through channel programs (loosely similar to machine code 
for channels). EBCDIC is native. Sure you can use ASCII however 
instructions to convert integer to packed to printable produce EBCDIC 
output.

Agreed, real hardware is required and not just older 370/XA or ESA hardware 
but 64-bit z/Series hardware. And they're expensive.

Additionally, disk formats are different. Even though current disks are FBA 
(fixed block architecture - with sectors), they emulate older 3380 and 3390 
CKD (count key data - variable length blocks) devices. Decisions regarding 
block size and space used by inter-record gaps must be considered, a 
space/time issue. Not only must the CPU architecture be considered but the 
I/O subsystem and how data is physically laid out on disk.

How would you support vi on a 3270, a different editor maybe? Serial 
terminals, network access, and any other terminals would require a network 
controller (in my day we used 3705 and 3725 controllers with network 
control program [NCP] loaded). BTW, an application on MVS, called VTAM, 
would load the NCP O/S into the network controller and manage network 
communication. In other words, this would be a big job.

Though I'm partial to the IBM mainframe architecture and instruction set -- 
I spent the first half of my career mucking around in the MVS kernel -- and 
would love to see FreeBSD support it, I cannot justify the huge effort. How 
many mainframes still remain and what would people use FreeBSD for on a 
mainframe? IMO there are more important and urgent things to work on, but 
at the same I don't think we should stop someone who has the cycles to 
spare and has access to hardware, unless the people involved are pulled 
away from other projects that could help FreeBSD.

It would be fun but is it realistic? I think that's why all attempts to 
develop a BSD for  the mainframe have stalled after a while, the people 
working at it became discouraged.

BTW, Linux doesn't run on the bare metal IBM mainframe either. It runs in a 
VM under z/VM. Maybe this is what we should try at first. z/VM can present 
mini disks which appear as FBA devices to the VM. No need to get a 
mainframe, just a VM account somewhere.


-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.