Almost makes flying civilised.

In addition to Gerardis, who produced “I, Robot,” Jeff Vintar, who penned the screenplay to that film, was attached to pen the “Foundation” screenplay.

I, Robot was at best an awful film. The Foundation film will most likely be worse.

The first and greatest threat from court decisions in California and Massachusetts, giving legal recognition to “gay marriage,” is that it marks the end of democracy in America.

So says Orson Scott Card. Shame; I enjoyed the “Ender” books.

As part of my work on Least Privilege for xVM, I worked on implementing direct file mounts. The idea is that we'd modify the Solaris support in virt-install to use these direct mounts, instead of the more laborious older method required.

A long-standing peeve of Solaris users is that in order to mount a file system image (in particular a DVD ISO image), it's a two-step process. This was less than ideal, as many other UNIX OS's made it simple to do: you'd just pass the file to the mount command, along with a special option or two, and it mounts it directly.

With my putback of 6384817 Need persistent lofi based mounts and direct mount(1m) support for lofi, this is now possible (in fact, a little easier) in Solaris. Instead of doing this:

# device=`lofiadm -a /export/solarisdvd.iso`
# mount -F hsfs $device /mnt/iso
...
# umount /mnt/iso
# lofiadm -d /export/solarisdvd.iso

it's just:

# mount -F hsfs /export/solarisdvd.iso /mnt/iso
...
# umount /export/solarisdvd.iso

Under the hood, this still uses the lofi driver, it's just automatically used at mount and unmount time. There's no need for an -o loop option as on Linux.

This is supported for most of the file systems you might need in Solaris, namely ufs, hsfs, udfs, and pcfs. This doesn't work for ZFS, as this has its own method for mounting file system images.

I was asked a couple of times why I implemented this in the kernel at all (which meant requiring file system support via vfs_get_lofi(). This was primarily to allow non-root users to access file mounts; in fact this was the primary motivation for implementing this feature from the point of view of the xVM work. In particular, if you have PRIV_SYS_MOUNT, you can do direct file mounts as well as normal mounts. This is important for virt-install, which we want to avoid running as root, but needs to be able to mount DVDs to grab the booting information for when installing a guest.

As always, there's more work that could be done. mount is not smart about relative paths, and should notice (and correct) early if you try pass a relative path as the first argument. Solaris has always (rather annoyingly) required an -F option to identify what kind of file system you're mounting, which is particularly pedantic of it. Equally the lofi driver doesn't comprehend fdisk or VTOC layouts.

Tags: Xen OpenSolaris xVM

Sikh girl wins bangle law battle

I’m sure there’s some legal argument that makes banning all
jewelry, religious or not, “discrimination”, but I doubt it’s a sensible one.
I wonder if they could add a watch face to it instead.

This one for the doubters (you know who you are): Likelihood of me being MALE is 100%

What are people’s approaches to writing Python correctly? The library documentation basically doesn’t document the set of exceptions the routines can throw, which makes it very difficult to catch the right things, and do the right thing[1] (for example). What do people do to deal with this problem?

[1] on that note, if you’re writing a command line tool in Python, please catch KeyboardInterrupt and exit quietly. Drives me crazy!

It’s somewhat disappoint that Mercurial is still corrupting repositories when you interrupt MQ operations.

Relatively easily recoverable for me this time, thankfully. I’d still like to see hg backup from the OpenSolaris SCM project get merged upstream though :)

After some searching and asking around I didn’t find any good explanation of the simplest way to implement plugins in Python. So, for posterity’s sake, here’s my solution. I’m sure there’s a better way: I’d love to hear your suggestions.

First, the requirements. The code cannot have knowledge of how the plugins are named (.so files, .py, package dirs, etc.). I don’t want to hard-code the list of plugins, as this defeats its dynamic nature altogether. I have to be able to iterate across all plugins. Any user should be able to use the module without knowing that it’s got plugins. Finally, it’s got to be as simple as possible.

First up, we have whatever/__init__.py:

import pkgutil
import imp
import os

plugin_path = [os.path.join(__path__[0], "plugins/")]

for loader, name, ispkg in pkgutil.iter_modules(plugin_path):
    file, pathname, desc = imp.find_module(name, plugin_path)
    imp.load_module(name, file, pathname, desc)

This basically uses Python’s module search to find all contents of the plugins sub-directory and load them. Now we have some more scaffolding in the same directory, as whatever/whatever.py:

plugins = []

class plugin(object):
   """Abstract plugin base class."""
   ...

def register_plugin(plugin)
    global plugins
    plugins += [ plugin ]

# utility functions to iterate across and use plugins...

Finally, each plugin looks something like this, in plugins/foo.py:

from whatever/whatever import *

class fooplugin(plugin):
    """Concrete class for foo plugin."""
    ...

register_plugin(fooplugin)

Simple enough, but it took a while to work it out. Unfortunately, it doesn’t seem possible to merge whatever.py into __init__.py as we have a recursive import problem.

Best cake ever.