Josef “Jeff” Sipek

I decided that RSS/RSS2 were evil, and that I was going to provide only Atom feeds. Cope.

Just update your aggregator to use the Atom feed instead:

http://blahg.josefsipek.net/?feed=atom

Alright, I’ve finally managed to write a little entry about this…

On February 26th, IBM announced a new series of mainframes: the z10. It’s still z/Architecture, although they expanded it a bit.

Here’s what it looks like (image shamelessly stolen from the internet):

So, what makes it better, you ask?

It’s faster (up to 64x quad-core 4.4GHz processors), it supports 3 times as much memory (storage in mainframe speak) as the z9 did (512GB -> 1.5TB), the cores are 50-100% faster depending on the load, and other goodies….I’ll just list them in a list…it’s more parsable that way:

• 64x quad-core 4.4GHz processors
  • 64 kB L1 i-cache
  • 128 kB L1 d-cache
  • 3 MB L2 cache

• z/Architecture
  • crypto, decimal floating point, and compression accelerators
  • 894 instructions, 75% implemented in hardware
  • 1MB, as well as 4 kB page tables (z9 has only 4 kB)

• 1.5TB memory (z9 had 512GB limit)
• 50-100% faster execution (depending on the workload)
• One z10 is equivalent to 1500 x86 servers, but uses 85% less power
• Available in the second quarter of 2008

IBM also announced that there’s a porting effort to get OpenSolaris to run on the z10.

Hello all!

I would like to announce the first public release of HVF — an open source OS for the zArchitecture written in C.

Currently, the OS does very little. It consists of:

- simple process scheduler
- console layer (currently supports only one 3215 device)
- page allocator
- slab allocator (to provide a libc-like malloc())

Once the system is IPLed, it outputs some information to the console, and then continues to idle. While this is not much there is enough code that it lends itself to (aside from my goal with it — see below):

- being used as a basis for experimenting with zArch
- being used as the beginning of a toy OS

Since I do not have access to a zSeries and therefore I had to resort to developing and testing on Hercules. It is possible that there are issues that need fixing to get things running smoothly on the real thing.

The ultimate goal is to have a VM/370-like OS that runs on the zArchtecture - to allow Linux and other modern OSes to run concurrently on a single machine. Here are few of the goals on the TODO list:

- nucleus should be all 64-bit (minus the arch mode switching code)
- mostly in C
- support multiple users
- use SIE to virtualize the hardware (S/390 and zArch modes)
- give something to the mainframe hobbyist community to play with :)

Note that this is all for the hypervisor — I’d like to have a CMS-like OS as well, but that’s secondary. (In a couple of days, I’m actually planning to post a list of ideas for the guest OS to the HVF mailing list — see below.)

You can find the released source code in a tarball at:

https://www.josefsipek.net/projects/hvf/src/

I use Git[1] as the version control system. You can browse the history, as well as obtain the source at:

http://repo.or.cz/w/hvf.git

Feel free to grab a copy of the source code, build it (see Documentation/building.txt in the source tree), IPL it, tweak it, and submit patches :)

I have also set up a mailing list as a place to discuss design, comment on code, etc.:

http://lists.josefsipek.net/listinfo/hvf

Currently, the list gets commit messages whenever something changes in the repository but I’m hoping that once people join it’ll be more interesting :)

Then there is the IRC channel where you can catch me pretty much all the time:

server: irc.oftc.net (the OFTC network)
channel: #hvf

And finally, I have decided to use GPLv2 as the license of choice for the code. The major advantage of doing so is the ability to borrow code (with proper citation of the borrowing) from other GPLv2 projects — namely Linux. The extent of the borrowing is restricted to basic building blocks — e.g., atomic variable types, locking primitives, but not much more beyond that.

Josef ’Jeff’ Sipek.

[1] http://git.or.cz/

So, as some of you may have noticed, this my server was inaccessable for a bit. That was because I moved it to a new home — now I have much easier time accessing it, as on average it will be about 5-7 meters away from me (instead of the ~250m). Let me know if you have any problems with it.

Here’s another update on my version control system escapades (a follow up to Do I have…).

As several people mentioned during the 0.10 release of gq, the name is already in use by a rather well established project. So, after some idleing and hacking, I decided that it was time to give the scripts a new name, and announce the new version on the git and linux-kernel mailing lists (the annoucement). I can’t take credit for the rather clever name, I asked a few people, and the best suggestion was by Dave - Git Quilt or Guilt for short.

One thing I did not expect was the fact that someone would contribute 2 patches very shortly after I announced it. Here’s the list of changes that made between v0.16 and v0.17:

Horst H. von Brand (2):
      Fix up Makefiles
      Run regression on the current version

Josef 'Jeff' Sipek (24):
      A minimalistic makefile
      Contributing doc file
      Added guilt-add
      Added guilt-status
      Expanded the HOWTO
      Added usage strings to all commands
      All arguments to guilt-add are filenames
      More thorough argument checking & display usage string on failure
      Changed status file format to include the hash of the commit
      Fixed guilt-refresh doing an unnecessary and somewhat wrong pop&push
      Fixed up guilt-{delete,pop} not matching the patch name properly
      Fixed guilt-{delete,pop} regexps some more
      Force UTC as timezone for regression tests
      Fixed a bug in guilt-pop introduced by the status file format switch
      Error messages should go to stderr
      Merge branch 'usage'
      Merge branch 'status-file'
      Yet another TODO update
      Added guilt-rm
      Makefile update & cleanup
      pop: Display the name of the patch from the status file, not the series file
      new: Create dir structure for the patch if necessary
      Documentation/TODO: Mark guilt-rm as done
      Guilt v0.17

I haven’t had much time to work on Guilt since then, but I got an rather encouriging email from someone, who tried to apply Andrew Morton’s -mm patch series on top of the kernel tree, but failed. The problem is with the way git-apply works. If it applies a patch with an offset, it still returns non-zero status. This makes guilt think that at least one of the hunks in the patch did not apply at all. As far as I know, there is no way to get the necessary information out of git-apply without either modifying it (which I might as well), or parsing the output for signs of rejection and ignoring the return status completely. I don’t like the latter, but changing git-apply would limit the number of compatible git versions. :-/

Needless to say, patches are welcomed :)

So, Pluto isn’t a planet anymore!