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




« July 2016