By user12619391 on May 17, 2005
Welcome, and thanks for stopping by.
I'm an engineer in the Solaris kernel group, currently living and working in Silicon Valley, USA. In my nearly six years in this group (and at Sun), I've worked on many things: consing up corporate LDAP database crawlers, carefully crafting Tektronix 4014-based multi-processor performance monitors, and occasionally making sure I can still boot the Brown Simulator (and run Weenix, of course) on our latest bits.
My more substantial (and alas, relevant) efforts include:
- Solaris 9: I was assistant technical lead for the ON consolidation (the kernel, and core commands and libraries portion of Solaris). Effectively taking on the role of Jessica Fletcher, I spent the release poking my nose in other peoples' workspaces and solving problems other people didn't want to (or worse, wanted to ignore). Though few mystery novels were written, each putback was filled with suspense and the release seemed to go on as long as the TV show. Co-stars: David, John, and Tim.
- System V IPC: Its numerous and often indistinguishable /etc/system tunables being the bane of the database administrator and desktop jockey alike, System V IPC was in need of a huge overhaul. The executive summary is that I removed the unnecessary tunables and I made what remained dynamically modifiable. The benefits extend well beyond these, but I'll leave them to a later, more detailed discussion on the damage a phone company can do to an operating system.
- The Service Management Framework (SMF): If you've been following Solaris 10 at all, you've no-doubt heard plenty about SMF, probably from one of Stephen, Liane, Jonathan, or Dave (Miner). It's a new way of managing system services which formalizes what a service is, how services depend on each other, how we should handle services which fail, and how we (and ISVs) deliver new services on top of Solaris. My contribution was the process contracts facility, which allows us to reliably track hardware, software, and administrator failures in processes and associate them with their services.
At the moment I'm working on/thinking about a couple things:
- Creating Java interfaces for SMF, so that people can build some good administrative tools on top of it. We already provide libscf(3lib), but Java bindings will expand the developer audience and will let us easily export SMF via stuff like JMX.
- Additional contract types. SMF's process contracts are actually just a component in a framework capable of supporting a wide variety of contracts. Contracts will hopefully let us do things like synchronously notify large applications that the specific resources they depend on are going away due to dynamic reconfiguration or predicted hardware failure.
But the mind can't comprehend what the eye can't endure; the first order of blog business will probably be some aesthetic improvements. Stay tuned.