Thursday Mar 31, 2011

Intentionally left blank

Well, almost blank. But definitely intentional.

Monday Jul 14, 2008

Ants should be telepathic

If they were, then when I kill one of the ants that appear in my bathroom, the rest would immediately realize that the ant's mission was one of folly. That only an ant expecting death should enter my bathroom. That zipping across my counter means a swift execution and watery grave.

But alas, they aren't.

Tuesday May 20, 2008

Visual Panels online help text now available

If you're using Visual Panels and are confused by a panel... it's a usability bug (please let us know). Normally we'd have online help to compensate for such inadequacies, but Java Help isn't available in Indiana yet. Until it is, we've posted the help text on the Visual Panels project page.

(Technorati) Tags:

Tuesday May 06, 2008

Visual Panels in OpenSolaris 2008.05

For a while I've been working on a project to ease OpenSolaris configuration called Visual Panels (with Steve and Tony, and a great deal of patience, insight, and fastidiously gathered data from Jaime). I'm happy to say that — as of the May 2008 release — it is now available in the Indiana IPS repository. Installing it takes at most three steps (as root):

  # pkg refresh
  # pkg install OSOLvpanels
  # svcadm restart manifest-import

The first step is unnecessary if you've refreshed since installing OpenSolaris 2008.05. The last would be if IPS supported SMF. \*pokes Stephen\*

If you are logged into Gnome, Visual Panels will be available as soon as you install the package and restart manifest-import. Though we started out by creating a console that contained the various sources of configuration, our usability testing showed the inconsistency with Gnome's presentation was confusing. So for the time being, we have "broken out" the panels as individual applications. Under System->Administration, you will now see:

  • "Apache Web Server"

  • "Core Files"

  • "Services"

  • "Shared Folders"

(Actually, the last two were there before and are silently hijacked when VP is installed.)

I feel like I should say more: perhaps go on a meandering, screenshot-appointed tour of every nook and cranny, or provide a cookbook of detailed instructions on how to do common things in VP. But after a very enlightening usability study where we started users off at the login screen and let them fend for themselves, I also feel like I should shut up and see what people's raw reactions are. The former (at least the meandering part) should be done eventually, but I will save it for another day. To avoid a flood of similar complaintscomments, though, I'll mention a few things you might run into that are on my short list of things to fix:

  • Role support. Support for roles came in the 11th hour when we discovered that root is a role on Indiana1. So when you want to log in using the root role (or any role), you have to re-specify your username and user password, in addition to the role name and password. Yuck.

  • Visual footprint. When you have a console, your components not only have a similar look and feel (a good thing), but often have a similar size (not a good thing). Because of their console ancestry, the Visual Panels apps unfortunately have a large visual footprint, and need to go on a diet.

  • Shared Folders. We've been struggling to get the right balance between flexibility and simplicity, and still aren't there yet. And then there are the bugs.

  • Start up speed. Starting a Visual Panels control panel takes a few seconds. It's easy to say that this is because we're using Java, but the truth is we have a lot performance work to do. (Launching more VP-based control panels after the first window is open, on the other hand, should be pretty quick.)

  • Documentation. Unfortunately, Java Help isn't yet in Indiana, so the online help our doc writer worked hard to produce is unavailable. When Java Help shows up, you should be able to just install the package and VP will detect and use it automatically. We plan on putting HTML versions up on the Visual Panels page shortly as a stop-gap.

Yes, there is also a long list.

Stay tuned for more about how VP works and what we're doing with it. (I promise my next post will come before another 2 years flash by.) And please let us know what you think. None of this is set in stone, so feedback, ideas, help, etc. are all greatly appreciated.


1...only if you create a non-root login during the installation process. Guess who was always installing without creating a non-root login?

(Technorati) Tags:

Monday Feb 20, 2006

The last Java wrapper script

One of my biggest Java pet peeves is the fact that a pristine, platform-independent Java application will frequently be shipped wrapped in a diseased blanket of shell scripting. Nominally, this wrapper script is there to set up the class path and invoke Java, acting as "glue" between the curmudgeonly operating system and this denarian virtual machine technology. The typical wrapper script is far from so reserved, unfortunately acting as a lint trap for all manner of minor enhancements presumably made in the name of programmer efficiency. In the long term, gratuitous use of multiple languages when one will do is the antithesis of efficiency (I am, of course, thinking of the poor guy who has to debug or maintain this stuff after the original author has skipped town).

As it turns out, a couple operating systems have support for direct execution of Java binaries. Coupled with an appropriately constructed JAR manifest (which can specify things often relegated to the wrapper script, e.g. the class path), this lets us eliminate these unsightly wrapper scripts in many cases.

Not all operating systems are so fortunate, though. I noticed this evening that trying to directly execute a chmodded JAR file under MacOS X gives me a disappointing "cannot execute binary file" error. To avoid introducing yet another garbage-collecting monstrosity to the world, and to avoid needing to create a new script for each new JAR I added to my growing army of Java commands, I decided to borrow a page from the isaexec playbook:

#!/bin/ksh -p
# executes the JAR file whose name is used to run this script

BASE="$(basename $0)"
DIR="$(dirname $0)"

[ -f "$JARFILE" ] && exec java -jar "$JARFILE" "$@"
echo $BASE: command not found
exit 127 simply takes argv[0] as the name of a .jar file in the jars subdirectory of the directory argv[0] is in. Using it is as simple as creating a link to it. For example, I put mycmd.jar in ~/bin/jars, and linked ~/bin/mycmd to the script. Done.

Unfortunately, not all Java applications can be simplified in this manner. Class paths may vary from install to install (something like $ORIGIN here would be a dream come true), and LD_LIBRARY_PATH might be needed to find native libraries. I'm keeping my eye on JSR 277; hopefully it will provide the solution my fellow wrapper-script haters and I long for.

(Technorati) Tags:

Monday Feb 06, 2006

Visual Panels debut

Long ago, I mentioned I was working on creating Java APIs for SMF. Well, the blogless David Bustos and I have done just that... and a bunch more. Check out the OpenSolaris Visual Panels page to read about our project to simplify end-user configuration on Solaris.

In addition to the aforementioned SMF interfaces, you will find:

  • A prototype GUI. It ain't pretty, but it demonstrates some of the integration we'd like to achieve.

  • A basic SMF service MBean. The GUI actually uses JMX instead of direct calls to our APIs as much as possible.

  • Source for all this, so you can rip out the parts you don't like and replace them. Or finish the parts we didn't. Or just fix our bugs.

Now stop reading this, and go look at some screenshots.

(Technorati) Tags:

Thursday Jul 14, 2005

Solaris tagging of a different sort

The wall bordering a gravel path I occasionally jog had some amusing graffiti on it:

Anger. Stop-A. Savages. Okay, perhaps "savages" isn't the first thing you think of after getting angry and hitting Stop-A, but uttering

: savages boot ;

at the forth prompt will make it reboot your SPARC box.

(Technorati) Tags:

Wednesday Jun 22, 2005

Bedtime Reading

Though much of the OpenSolaris kernel is well commented (or at least, clearly implemented), there are a few files where we have gone out of our way to describe the big picture... or explain the subtle details. Sometimes called "Big Theory Statements", these descriptions usually take the form of a huge block comment near the top of a file and can be read from start to finish. I often point new hires eager to learn more about the kernel to these as straight-up reading material. When friend with a penchant for reading source code mentioned this weekend that he spent some time in page.h, it occurred to me that many would appreciate a list of files they could curl up by the fire with.

For starters, I usually recommend checking out the implementations of our kernel synchronization primitives:

turnstile.c the foundation for synchronization objects that have owners
mutex.c mutexes
rwlock.c reader-writer locks
sleepq.c sleep queues

It is with dismay that I point out that condvar.c — with its not one, not two, but eight different variants of cv_wait — is deservedly absent from this list.

The other well-documented files on my list hail from all corners of the kernel:

cyclic.c high resolution interval timers
dtrace.h DTrace
errorq.c kernel error queues
ipc.c System V interprocess communication
kstat.h kernel statistics
page.h all about pages
vmem.c the foundation for kernel memory allocation
zone.c zones

I offer apologies in advance if I've left out your favorite (dev_rmscsi.c, though to be admired for its candor, doesn't qualify). Let me know and I'll add contenders to this list... and to my own.

Tuesday Jun 14, 2005

Simplified Pseudo-Filesystem Implementation

A common complaint we hear from Linux users who try Solaris for the first time is that our /proc sucks. "Sucks" in this case usually refers to either the fact that you can't cat files under /proc and get text out, or the fact that we don't have things like /proc/pci. The former is a flamewar for another day; right now I want to drill down on the latter.

The idea behind the Solaris /proc is simple: export information about the process model (hence its name). We try not to put other stuff there. This begs the question: "Where does other stuff go?". Some functionality is available from libraries or devices, other functionality might not be available at all. But some functionality may be best suited for a hierarchical namespace like... a filesystem.

To satisfy the need for pseudofilesystems interfaces and the desire for consistent nomenclature, we've introduced a /system directory in Solaris 10. /system is intended to contain mount points for file systems which export non-process system information. Under /system we currently mount two new filesystems, the contract filesystem (ctfs(7FS), at /system/contract) and the kernel object filesytem (objfs(7FS), at /system/object).

Now that we have a home for this kind of thing, and now that OpenSolaris is open for business, there are many opportunities for the industrious to fortify Solaris with the filesystem conveniences they desire. Of course, just because there's an opportunity doesn't mean it's easy. There's a lot of work involved in interfacing with the parts of the kernel you want to interact with, and a lot of work involved in writing the FS glue. The latter is actually the insidious part; if you've spent any time perusing the source under usr/src/uts/common/fs, you've probably noticed that most of the filesystems are copy-and-pasted from each other and often reimplement a lot of complex algorithms. I consider this a badge of shame, but the practice dates back to the earliest days of the OS (in other words, there's no-one left to pin this badge on).

One of the projects I worked on in Solaris 10 was SMF, for which I was responsible for creating a process tracking mechanism. The result was process contracts, and we decided that the most appropriate interface for process contracts was a fileystem.1

Having spent a lot of time reading filesystem code, I was familiar with the mistakes of the past and for the sanity of my successors was determined not to repeat them. To make a long, uninteresting story short, I ultimately created a library of abstractions called gfs which I used when implementing ctfs. With these abstractions I was able to tuck away a lot of the complexity of implementing common fs entry points such as VOP_READDIR, leaving behind a relatively simple filesystem-specific implementation. When Eric later wrote the objfs filesystem, he spent a lot of time refining the gfs interfaces to be even more streamlined.

The end result is that it is now pretty darn easy to create pseudo filesystems on Solaris. For a rough before/after comparison, check out this behemoth, weighing in at over 70 lines of grungy C code. I hope we never have to write something like it again. The equivalent from ctfs is much cleaner:

static int
ctfs_tdir_do_readdir(vnode_t \*vp, struct dirent64 \*dp, int \*eofp,
    offset_t \*offp, offset_t \*nextp, void \*data)
        uint64_t zuniqid;
        ctid_t next;
        ct_type_t \*ty = ct_types[gfs_file_index(vp)];

        zuniqid = VTOZ(vp)->zone_uniqid;
        next = contract_type_lookup(ty, zuniqid, \*offp);

        if (next == -1) {
                \*eofp = 1;
                return (0);

        dp->d_ino = CTFS_INO_CT_DIR(next);
        numtos(next, dp->d_name);
        \*offp = next;
        \*nextp = next + 1;

        return (0);

As you can see, there's little boilerplate. In fact, the function's body is almost completely specific to reading a ctfs template directory2.

The next step is obvious: we need to take some time and re-factor existing filesystems to use these interfaces wherever possible. As part of my initial putback I also reimplemented parts3 of /proc to use them4. A more thorough eye needs to be turned to /proc to finish the job (and perhaps elevate its low-level gfs usage to complete gfs management5), and things like fdfs have little reason to be ignored.

What have we learned here?

  • /system is our home for new pseudo filesystems.
  • Copying old code is a bad idea.
  • Factoring code is a good idea (and fun, because you usually get to delete the aforementioned old code).
  • ctfs and objfs are good examples to follow when writing your spiffy new pseudo filesystem.
  • I like footnotes.

We've made other refinements to our file system implementation in Solaris 10. Things like the new file system interfaces (which replace the crusty, fixed-length vnode and vfs definitions with an opaque structure initialized with a variable length parameter list) have done much to improve the sanity of filesystem developers. I encourage you to explore our filesystem code; perhaps you'll find a new class of improvements we should make (or even make them yourself!).


1I'm not sure this was the wisest choice, but it seems to have worked out all right.

2"But what is a template directory?" you may be asking yourself. I'll elaborate on contracts another day.

3At the time I was already modifying a bajillion popular kernel files, and wasn't eager to add more to the list. To avoid unnecessarily complicating my merge process, I only rewrote those few functions which didn't require coordinated changes in other files.

4I had already added a bunch of code for some contract-related entries in /proc, and wanted to "restore balance to the force" by removing an equivalent amount of code. Perhaps surprisingly, we tend to get more excited about an opportunity to delete code than an opportunity to add more...

5See the comment at the top of gfs.c.

Monday Jun 13, 2005

FISL Wrap-up

Alas, this comes a week late.

The whole Sun crew

Team Sun

Looking Glass demo

Dimas demos Looking Glass

Charlie talks about NetBeans

Charlie talks about NetBeans

Eric talks to some new CS students

Eric talks to some new CS students

FISL continued to be a fantastic experience. While on the first day (ignoring our formal morning session) we pretty much just hung around and talked with whomever we could lure to our booth with the promise of free t-shirts, DVDs, and candy1 (not to mention software), we tried to make the second and following days a little more structured. There is a lot of cool stuff in Solaris, and we wanted to make sure that some of the lesser known technology saw the light of day. Though we quickly discovered we could have spent the entire conference demoing Project Looking Glass and DTrace, or chatting about OpenSolaris, we felt obligated to try to break the popularity feedback loop.

We broke the last three days down into hour-long segments, and assigned topics to each. For each topic we had2 a short presentation we expected to consume only about 15 minutes, and left the rest of the time open for questions and discussion. This of course varied from subject to subject (e.g. DTrace was demo-heavy, OpenSolaris was more interactive), but the idea usually held. We posted the next two hours of topics on a side outside our booth and waited. Sometimes people would show up, sometimes not. While it may have been the case that the Fault Management Architecture and the Service Management Facility topics simply were poorly scheduled against some of the larger conference presentations, I personally think they suffered most from the lack of sexy names (as an engineer, I have a subconscious aversion to anything having to do with "Management"). Certainly the people who attended each found them interesting enough to stay through our presentations and ask a lot of good questions; perhaps all it would have taken to draw a larger initial crowd would be if we had done some spontaneous marketeering. We'll have to try "The Hardware Bouncer" and "SMF: Booty Guru" next year.

The other topics were more successful. Talking about Open Solaris was, of course, a lot of fun. Since I didn't get too many questions on the development mechanics part of my pre-session talk, I left that part out of my booth talk. I don't think it was missed (which is a little disappointing, but also understandable -- it's hard enough for a native English speaker to follow the volume of terminology and acronyms introduced). My only awkward moment during the conference had to be when, in my first Open Solaris booth talk, I tried to illustrate the possibilities of what the community could do with Open Solaris that Sun would not. Needing an appliance to use as an example, I quickly chose TiVo. While very recognizable in the US, I can't imagine they exist at all in Brazil. Upon seeing a sea of blank faces, I quickly backpedalled to the generic "personal video recorder" which, judging by the unchanged gaze of the crowd, was still a lost cause. Then -- and I have no idea how I got there -- I said "or a car". Few people design software for their cars, and those who do so for a living apparently have a hard time of it. That's when I decided to cut my losses and move on to my next bullet. The following day I ditched the appliance idea entirely and instead used the example of a MIPS port which was easily understood by all.



Our booth was open and inviting, and spacious enough to allow multiple large simultaneous conversations. Unfortunately, this meant it was a difficult for one unmiced person to fill the space, especially with the high ceiling catching a lot of the ambient noise in the hall. Miraculously we all seemed to escape with our voices intact. We had a well-stocked fridge in our booth; after some experimentation I found that soda was much more effective at soothing my throat than plain water. Much to my chagrin, the local staff quickly (after only my second can) dubbed me "Coke Boy". It was certainly a misplaced nickname, as I very seldom drink soda back in the states3. That said, I found the taste of the local soda Guaraná very appealing; it's a shame it isn't common in the US (assuming you can get it at all -- something I need to check the next time I'm at BevMo).

CodeBreakers and Solaris

CodeBreakers and Solaris

The high point of the conference was, without a doubt, the people we met. Going to an open source conference as emissaries from a not-yet-open-source operating system, I was concerned we would be facing a surly welcome. To the contrary, almost everyone I talked to seemed more focused on technology than dogma. A few were justifiably skeptical4, but most were eager to see what were about, if not install Solaris as quickly as they could. It is almost inconceivable that the original plan was to bring 10 DVDs; we went through enough of the couple hundred we brought on the first day that we had to carefully ration the remains5. Perhaps the most enthusiastic were Thiago, Iru, and others from CodeBreakers, who are already working to form an OpenSolaris user group in Brazil. Hopefully we'll be able to make it to CONISLI in November to see them again, and the group they have started.

As much fun as the conference was, it was exhausting. We all slept extremely well the last evening.


1As Eric quickly discovered, the metallic wrappers around the chocolate candies would make a silvery mess of anyone's hands who ate enough of them. This was not intentional.

2Often written the night before. Or sometimes just a few hours before. Interestingly, the more impromptu the materials, the better they seemed to be. It shouldn't be too surprising; this let us tailor the content to our audience, which is always a recipe for more effective communication.

3 I suppose it's better than "Crack Baby".

4 While Sun has a long history of contributing open source, Solaris is unlike anything we, or anyone else, have done before.

5 Which for me meant: give one to anyone who came up to me and asked.

Wednesday Jun 01, 2005

Greetings from FISL 6.0

the Sun booth

Our booth

Eric and I (and a cast of many blogless others) are currently in Porto Alegre, Brazil representing Sun at FISL 6.0. FISL is a ginormous Brazilian Open Source conference; it seems very fitting that we be here given the impending release of OpenSolaris. Over the next three days we'll be spending a lot of time in our booth giving mini-presentations about specific Solaris features and generally about OpenSolaris. Please stop by if you're around and have questions. Or even if you just want a t-shirt.

Eric presenting

Eric presenting

Tom presenting

Tom presenting

So far it has been an interesting experience for me; it's the first time I've seriously ventured into the southern hemisphere, to say nothing of Brazil. It's also strange, shortly after spending a few months in China clawing my way up the language ladder to the point where I could have simple conversations, read menus, and get myself around, to be once again thrust into a situation where the language is a significant barrier1,2. Fortunately, the fears of being unable to communicate with other conference attendees that were forming after my first, almost-exclusively Portugeuse 24 hours in Porto Alegre where dashed when at our pre-event session we had a sizeable English-speaking audience armed with lots of intelligent questions. At the left you can see Eric presenting new Solaris features in a pose deserving of a scribbled-in mustash and red armband -- all I can say is that it is better than the other photo I took, unpublished here, which will simply be referred to as "the action shot". In contrast, Tom Goguen, speaking about OpenSolaris, has clearly taken the SunU class on avoiding dictator-like poses. (No-one thought to take a picture of me, fortunately; my camera karma is quite bad).

DTrace demo

DTrace demo

For the rest of the day we hung around the booth, chatting with anyone who stopped by. The most common queries regarded Solaris features they've heard about, how much we were charging for the Solaris 10 DVDs and OpenSolaris t-shirts we were giving away for free, and how they could get OpenSolaris today. Obviously some people came away happier than others, but on the whole I think most people had a good time -- we certainly did. The questions we got were great, and it was fun to be able to talk to such a technically-savvy crowd. I'm definitely looking forward to the next couple of days.


1The existence of cognates is a welcome crutch.

2There have been many occasions where I have caught myself about to say "那个..." -- a sign that at some subconcious level my brain believes that speaking any foreign language would suffice.

Tuesday 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.




« July 2016