Early in my professional career I had two different opportunities at Sun Microsystems. The first saw me as a summer intern up in Burlington, Massachusetts working on what would become the UltraSPARC T3 though at the time was just known as KT doing hardware verification working on part of the I/O chip that was responsible for PCIe, MSIs, and MSI-X support. Little did I know that would be the start of a long period of time straddling the hardware and software boundary.
From there, I found myself spending a summer instead with the Fishworks Team which affirmed a belief that I had that by better understanding hardware we could write better software and vice versa. At Joyent, after that, I spent a lot of time on everything from network virtualization to hardware support, fighting with side-channel vulnerabilities, and the never-ending slog of bugs that were usually either psychotic or reproducible.
At the beginning of September, I decided to take a break. After catching up on some neglected reading, wrting, games, working on a new Call of Cthulhu one-shot, and spending a lot of time experimenting in the kitchen, I eventually decided it was OK to start thinking about code again and asked myself what was going to excite me and what was next.
After working on various aspects of getting systems to boot, wiring up sensors, getting excited by something as simple as an interrupt firing, cursing at firmware, and making LEDs blink, you’d think I’d have internalized the ups and downs of working at the boundary of hardware and software and that I had opened far too many 1500+ page PDFs. But it turned out that there was a part of this that I still wanted to tackle that I hadn’t had the chance to do.
While I had worked on software to better take advantage of hardware, and had briefly tasted the forbidden fruit of the idea of modifying hardware to better support software at Fishworks: an opportunity came up that would give me the chance to really take a swing and ask, if we’re going to really design hardware and software together, what could we do? That opportunity is Oxide Computer Company.
Oxide, founded by Jessica Frazelle, Bryan Cantrill, and Steve Tuck, is looking to tackle that with a focus on rack-scale computing. Here we can ask the question of how would you design the software to manage a full rack from first principles. What if instead of having to support every vendor under the sun and having to support the lowest common denominator, you have full control and can specifically co-design the full rack? What should management look like? What if you can control all the platform firmware? Why do you need a full BMC?
I’m excited to join the team at Oxide and get a chance to tackle some of these problems. If you’d like to read more, you can read more about Oxide from the mouth of Jess, Bryan, and on the Oxide blog. And if you want to hear some amazing tales of folks who have worked on the hardware/software boundary for years you should listen to the On the Metal podcast.
Previous Entry: Updating CPU Performance Counter Support in illumos| All Entries | Next Entry: Lessons from the Unix stdio ABI: 40 Years Later