Thursday August 05, 2004

The fate of "hot patching" (DUKS) and a new way of doing it

Way back when Solaris 8 was being developed, I came up with a way to dynamically revector the flow of execution in a running kernel. This idea came about because a large number of the bug fixes we were producing for customers were fairly simple...not all of them but quite a few. Customers were being forced to install new kernel binaries and reboot to verify our fixes, which introduced additional delay into the time it takes us to produce a patch.

By being able to load a replacement bit of code (via the loadable module mechanism) and revectoring the execution flow, we could allow our customers to try out the fix without having to wait for their next scheduled downtime. Sadly, it was never possible to do this for formal patches because the dependencies in the patches were invariably too extensive. That's ok, because it was only really intended to get a preliminary bug fix or diagnostic code change into a live kernel quickly.

One of the biggest problems with implementing something like this is that the architectural design of the operating system software needs to have this facility designed in. There are a number of ways to try and "retrofit" the capability but none of them really work very well.

Anyway, that got me thinking about how we could implement such a facility from scratch - should we ever get the chance. Well, last December I was implementing a VM layer on an toy x86 operating system I was writing at home and it occurred to me that we could use a similar method to the way address translation is performed with page tables and apply it to this problem. In fact, it wouldn't take a huge leap of technology to hardware accelerate the translation process from 32-bit code to function (method) address because the ability to walk software maintained tables is already in the hardware. Woohoo! A high performance dynamically updateable software architecture!

I've had a paper on this published via the Research Disclosure Database so rather than go into detail here, if you're interested just read the paper.

Use the Source, Luke...(it's open)

Psst! Have you heard that the Solaris source code will be opened to the community? Yes, it's true and this was a topic of discussion at a recent OSCON.

There's enormous momentum within Sun to open up the Solaris source code and embrace the open source community. I'm a member of the OpenSolaris council (also known by it's internal codename "tonic") and I can tell you,the timescales are aggressive!

One of our blog readers, Yusuf Goolamabbas, emailed me with a great idea...how about having publically accessible build machines for OpenSolaris? We think this exactly what we need to do. I forwarded his proposal to the OpenSource council and so far, it's been well received. Hopefully, we will have Solaris 10 servers with secure "developer zones" where you can login, take a child of the source and start strutting your funky stuff! Watch this space - and don't forget to join the OpenSolaris developer community when it's launched. I believe a web site for this is in the pipeline already.

Of course, there may be some skeptics out there. How will we make money by doing this? Why will the community want to participate? Well, the answer is simply that the passion within the engineering community at Sun for both Solaris and the open source community is enormous, a fact that has been largely opaque to the outside world so far. Furthermore, the technology we've got in Solaris now is just too good not to share!

We will open our source. Will you open your mind?