about the web, software etc. Recursion, n.: see 'Recursion'

Soon after my family and I had moved to the USA, we noticed something which had registered with me only subconsciously during some of my former visits to the country: 

Americans seem to be much more tolerant of noise than Europeans (those that we know, anyway).

This can be seen in the following examples:

• Highways cut right through residential areas.
• The windows in the places we looked at before we found our current home are all quite shabby, you can hear the traffic from miles away (esp. from aforementioned highways)
  
• The forced-air heating many places use makes a terrible racket - we had to turn it down in our bedroom because we couldn't sleep.
• Very many cars emit a loud beeping noise when backing up; I can understand the desire to have this in a trailer or truck that's half a mile long, but in a pickup?

Needless to say, this is not the case in the places I lived at before we moved, so some adapting has been going on. Luckily, our kids seem to be very good at this; I don't get the feeling that the noise is causing them to lose any sleep.

I would like to know though if anybody can come up with a good explanation for the above observation. I don't think that American ears are inherently less sensitive than ours, so there must be a more complex answer ...

I'm happy to report that Harley Hahn's recent book, "Harley Hahn's Guide to Unix and Linux", appeared on my doorstep a few days ago. 

Why is this relevant to me and to Sun?

It's relevant to me because I reviewed the whole book, chapter by chapter, as Harley wrote it. I was by no means the only person to do so, as you will see when you read the acknowledgements, but I'm proud to have been part of the effort. This is a new book following Harley's earlier "Student's Guide to Unix" and "Harley Hahn's Student Guide to Unix"; I've now done this (ie, review a book on Unix for Harley) for the third time, but still there's a lot to be learned from helping (if only a little) on such a project.

I also believe it's relevant to Sun, as I helped convince Harley to use Solaris as a test platform for his examples, besides Linux and FreeBSD (Harley was kind enough to forward me some snippets of my own emails proving this). I need to thank my colleague and former team mate Helmut vom Sondern, as he was kind enough to let Harley access a zone (and was very helpful keeping it accessible from across the Atlantic) on one of his systems to do all those tests (Antoon Huiskens also helped initially).

Initially, I got involved in this effort in 1992, when Harley sent out a message on comp.unix.questions, titled "Request for opinions about a new Unix book" (here's the complete message), which I saw and responded to. Apparently, Harley saw some merit in what I had to say, and I ended up reviewing the whole book (which then became "A Student's Guide to Unix") for him. Since then, I also reviewed the 2nd edition and various other books about the Internet for Harley, though none in as much detail as the Unix books.

I've stopped reading usenet since (mainly for the sheer volume), but it shows what can happen if you're not careful ;-)

You might like to know that the artwork on the book's cover, as shown in the picture, is from one of Harley's own paintings - he has quite a few of them at home! There's still a debate going on whether he's a better author or a better painter.

Research indicates that one's first public entry in a blog say something about oneself. I'm too conventional (this is the first statement about myself) to break with that, so here's an introduction of sorts ...

Why the name?

I've been using the line "Recursion, n.: see 'Recursion" in my email signature for years. The idea is definitely not mine, but I liked it the moment I saw it (in a book, the title of which I forget, that's a kind of "computer terms for dummies", which I was given for a birthday too long ago to remember). One day, when the occasion for a .sig change came up, it popped into my head, and there it was.

While contemplating a title for this blog, it occurred to me that many things, foremost the Internet (or "the web") and software tend to refer back to themselves - the Internet through its essential mechanism, the link (aka URL), and software in the form of functions, procedures or subroutines (essentially, pieces of code organised in units) referring to themselves. This can be quite tricky, especially if you need to debug it, as it comes in two slightly different shades: direct recursion is the more obvious, as a function calls itself directly (hopefully with modified arguments), whereas indirect recursion refers to the case where, between two invocations of a function, there are one or more other functions in the call stack (a note to the language-conscious reader: English is not my first language. Therefore you may spot something now and then that looks like German written with English words ... consider yourself warned).

Who am I? (who cares? I do!)

I've been with Sun for quite some time (too long, some would argue) - since November 1998, to be precise. I spent eight years in the support organisation. During that time, it was my job to handle incidents with and on Sun equipment, and more importantly, Solaris, that customers with service maintainance contracts would report. I specialised in crash dump analysis and performance stuff , but of course a lot of other stuff crept in (if any of my former customers thinks the name sounds familiar: you're right ;-).
I managed to transition to the Engineering organisation at the end of 2006, and moved from Bavaria to the Bay Area (hmm ... that's almost the same sound ...) with my family in March 2007. I now work in the Solaris Networking group as a software engineer.

Before joining Sun, I held a few software engineering jobs in Austria, my home country.

What do I do (when I'm not working)?

As I indicated above, I have a family (no pictures here, sorry), and I spend most of my free time with them. Luckily, my wife shares my passion for photography, so now and again we manage to get some nice pictures taken (in our opinion, anyway). I'm still thinking about how to publish some of that (or links) here ... stay tuned, but don't hold your breath.
We both have a strong background in traditional Austrian/Bavarian Volksmusik ("folk music" is a translation that IMO does not perfectly fit the bill - if you know German, take the time to read up on it). We've both played in various groups over time, and sorely miss the opportunity to do so in California (if you know someone who's proficient in that area looking for people to join, or if you are such a person, drop me a line!) - two isn't a group (not with our instruments, anyway) and our kids are too young to be any help there.
I also like to read, although I won't bore you here with a list of titles or authors. That does not mean I won't in future entries!

The last year, since joining the Engineering organisation at Sun, I've been working on what started as the xen project (a port of the opensource xen project to Solaris) but, for reasons I won't go into, had to be renamed to xVM, a name which has since taken on almost a life of its own and is now an umbrella for a lot of the virtualisation technology at Sun.

A few words on what xVM is and how it works: xVM is a technology for running more than one instance of an operating system (such as (Open)Solaris or Linux) on the same physical machine at the same time. To provide isolation for the running OS instances, also called (guest) domains, or guests, from one another, xVM provides a thin layer called the hypervisor which acts like a virtual machine towards the running domains. The hypervisor exposes a set of interfaces to these domains by means of which the domains can access HW and communicate with one another and the outside world. This implies that the OS in question be made aware of the fact that it's running on top of the hypervisor, this is called paravirtualisation.
There are also provisions to run an OS completely agnostic of the underlying hypervisor; in xen parlance, this an HVM or fully virtualised guest. These require an additional emulation layer for I/O, which costs a performance penalty.
Finally, there are paravirtualised drivers for otherwise unmodified guests to work around the cost of the aforementioned emulation layer.

The hypervisor itself is minimal, for administrative stuff (like starting guest domains) and for things like access to network cards etc, it requires a privileged guest, dom0. All other guest domains are called domUs. (There is work underway to let domUs access eg. I/O HW directly, so the above description is a bit out of date, but it's sufficient for the following discussion.)

Opensolaris.org hosts a xen community page, where you can read a lot of good stuff about this effort.

Coming, as I was, from the Networking group, I worked on - surprise! - networking stuff, specifically, on network communication between domains.
Currently, domUs cannot talk to one another directly (something our friends from the LDoms league have already achieved), but have to go via dom0. You can see an illustration of the data flow here (and thx to my colleague David Edmondson for letting me share this). If you're familiar with the way this looks in Linux, you'll notice some difference. This is due to vnics, technology we borrowed from the crossbow project at an early stage, another part of our overall virtualisation strategy that's coming along nicely. More below. A word on names: in Xen parlance, a communication channel consists of a frontend and a backend. The frontend lives in domU, the backend lives in dom0 (therefore xnf and xnb)

There's two distinct mechanisms that can be used for transporting data between domains: page flipping and hypervisor copying. For page flipping, the hypervisor sets aside some of its own (fairly limited) memory, which can then be used to transfer data between domains, involving repeated mappings into and out of the domains' address space. For hypervisor copy (HVcopy), OTOH, guest domains set aside their memory and indicate this memory to the hypervisor, which copies data into this memory at another domain's request (in our case, only dom0 - this means that for now HVcopy is only used for moving data into a domU, not out)

When I joined, only page flipping had been implemented for xVM, but it was found desirable to also have hypervisor copy. The reasons I can dredge up from memory are:

1. in high-load situations, the hypervisor would run out of pages available for page flipping, which would cause tons of error messages on the console and a significant drop in NW throughput.
2. some Windows (drivers, AFAIK Windows itself has not been paravirtualised) only "speak" HVcopy, and we intend (Open)Solaris to be able to host Windows domUs as well.
   
3. expected performance increase.
   

I implemented HVcopy for xnb and xnf, and am happy to report that we successfully addressed issues 1 and 3. We could not find Windows drivers that would interoperate with Solaris as domU (corrected:) dom0, so that is as yet unresolved.

As I mentioned above, the vnic code we got from the crossbow project which we incorporated into the xVM code, and which was putback to Nevada in build 75, was a very early version, and this code has seen some significant change in the crossbow project itself since. Recently, I updated the relevant parts of the xVM code (xnbo, xnbu) to the new "look and feel" of the crossbow API - this means that as of about mid-January, it is possible to for the crossbow "bits" to be booted as dom0, to start domUs, and - this is what it's all about, obviously, to successfully move network traffic in and out of the guest domains. As crossbow itself is not a part of Nevada yet, this change has only taken place in the crossbow "gate" (the copy of the Nevada gate where the crossbow development happens). Please refer to the crossbow community pages for when you can download what.

Update: Nicolas Droux pointed me to a more detailed document about network virtualisation in Solaris. Thx.