As a trivial example of the design scenario I was working with, consider the case of an object-oriented vegetable garden. Vegetables come in all shapes, sizes, and colors, but we might want to say that all vegetables should be green unless we’ve said otherwise. We might start modeling our vegetable garden with a Vegetable class, and we could set a color attribute on it with a default value of "green". Lettuce, which happens to be green, could inherit that attribute from Vegetable. Eggplant, however, should redefine color to be "purple".

While certainly a contrived and flawed example, it demonstrates the behavior I was looking for. Let’s see how Ruby’s various flavors of class attributes can help us solve this design problem — or not.

First up, class variables:

class Vegetable
  @@color = 'green'
  def color
    @@color
  end
end

class Eggplant < Vegetable
  @@color = 'purple'
end

Vegetable.new.color  # => "purple"
Eggplant.new.color   # => "purple"

I wasn’t expecting that! Apparently class variables are shared among subclasses, so you can’t redefine their value in subclasses without changing the value in the base class.

Next up, class instance variables:

class Vegetable
  @color = 'green'
  class << self
    attr_reader :color
  end
  def color
    self.class.color
  end
end

class Lettuce < Vegetable
  # no need to set @color here, since lettuce is green ... right?
end

Vegetable.new.color  # => "green"
Lettuce.new.color    # => nil

No love here, either: class instance variables are not accessible from subclasses at all. Probably for the better, since the code needed to access class instance variables from instances is even uglier than that needed to access class variables from instances.

Class constants are right out:

class Vegetable
  Color = 'green'
  def color
    Color
  end
end

class Eggplant < Vegetable
  Color = 'purple'
end

Vegetable.new.color  # => "green"
Eggplant.new.color   # => "green"

Class constants are statically bound, so the polymorphic call to Vegetable#color from an Eggplant instance references the Color constant defined in Vegetable, not the one defined in Eggplant.

Giving up on the class attributes approach, I resorted to defining the attributes at the instance level. I considered explicitly setting a @color instance variable in the class initialize method, but then the attribute wouldn’t be constant. Instead, the simplest implementation that does what I want seems to be to use methods that return constant values:

class Vegetable
  def color
    'green'
  end
end

class Lettuce < Vegetable
end

class Eggplant < Vegetable
  def color
    'purple'
  end
end

Vegetable.new.color  # => "green"
Lettuce.new.color    # => "green"
Eggplant.new.color   # => "purple"

So as it turns out, each of Ruby’s class attribute mechanisms behaves differently in subclasses. I’m sure class variables, class instance variables, and class constants have their utility, but they aren’t useful for defining constant attributes shared by all instances of a class, but which can be redefined in subclasses.

Continuations fit the bill nicely. These are functions from which you can return multiple times, resuming right where you left off. With continuations, you could write a sequence of functions that might make asynchronous calls, but the framework would call your continuation back where it left off.

Python does not have first-class continuations, but it does have generators, and these behave almost identically (for my purposes, at least). A generator is a function that can yield multiple values. Well, actually, it returns an iterator, which then can be used to fetch multiple values from the generator. An example will probably make it clear:

>>> def finite_generator():
...     yield 'apple'
...     yield 'orange'
...     yield 'pear'
...
>>> iterator = finite_generator()
>>> for fruit in iterator:
...     print fruit
...
apple
orange
pear

Generators can also run forever:

>>> def infinite_generator():
...     i = 0
...     while True:
...         yield i
...         i += 1
...
>>> iterator = infinite_generator()
>>> for i in iterator:
...     print i
...
0
1
2
3
4
5
... and on and on forever

I had been using iterators in my asynchronous host scanner whenever I needed to run asynchronous commands within a loop. The asynchronous programming model prevents you from writing something like:

for foo in bar:
    async_method(foo)

Instead, you would do something like this:

def callback(response, iterator):
    do_something_with_response(response)
    schedule_next_task(iterator)

def schedule_next_task(iterator):
    try:
        foo = iterator.next()
        deferred = async_method(foo)
        deferred.addCallback(callback, iterator)
    except StopIteration:
        pass

iterator = iter(bar)
schedule_next_task(iterator)

It works like this:

1. We get an iterator for our list, bar — this could just as well be a generator function
2. We fetch the first value from the iterator and pass it to the asynchronous method
3. That method presumably makes some type of I/O request, and responds immediately with a Deferred instance
4. We add a callback function to the Deferred and request that our iterator instance be passed to it when it is called
5. Control returns to the event loop, which might be busy scheduling other I/O requests
6. When the I/O completes, the event loop calls our callback function with the response and our iterator instance
7. The callback processes the response, and then repeats to step 2, fetching the next item from the iterator
8. When the iterator is exhausted, the cycle stops

It occurred to me that I might be able to extend this concept to use generators as a sort of continuation to emulate synchronous code. What if, instead of returning strings or numbers from a generator, you returned functions? Some wrapper code could initialize the iterator, and then loop over it using the technique above, calling each function returned from the generator.

Tonight I decided to give this a try. Forking off an experimental branch and making a few modifications to the underlying fido host discovery routines, I crafted the following pleisiochronous host scanner:

#!/usr/bin/env python
#
# Use a generator to simulate synchronous execution on an asynchronous framework
#

from fido.common.command import RemoteCommandExecutor
from fido.common.host.unix import UnixHost
from fido.common.ssh import SSHCredentials

from contrib.host.software.sun.host import SolarisHost
from contrib.host.software.linux.host import LinuxHost

from twisted.internet import reactor

import pprint

class PlesiochronousHostScanner(object):
    """
    Scans a host over SSH, building a list of host attributes. Built on the Twisted asynchronous
    library, but uses a Python generator function to emulate garden variety synchronous code.
    """

    def __init__(self, address, credentials):
        """
        address: the IP address to scan
        credentials: a hash like: { 'username': '...' , 'password': '...', 'public_key': '<optional>' }
        """

        self.address = address
        self.credentials = credentials
        self.host = UnixHost(RemoteCommandExecutor(address, credentials))
        self.pp = pprint.PrettyPrinter()

        # create some scratch space for the discovery methods
        self.context = { }

        # get an iterator from the generator
        self.iterator = self.scanning_sequence()

    def scanning_sequence(self):
        """
        A typical nugget of synchronous code, with one important exception: asynchronous
        functions must be yielded instead of being called directly.
        """
        yield self.host.uname

        os = self.context['uname'].split()[0]

        if os == 'SunOS':
            self.host = SolarisHost.from_host(self.host)
            yield self.host.zonename
            yield self.host.zones
        elif os == 'Linux':
            self.host = LinuxHost.from_host(self.host)
        else:
            print "Unable to scan host type: %s" % os
            return

        yield self.host.hostid
        yield self.host.device
        yield self.host.bios
        yield self.host.installed_memory_in_MB
        yield self.host.interfaces

    def callback(self, response):
        self.context.update(response)
        self.schedule_next_task()

    def errback(self, error):
        print "scanning error: %s" % error

    def schedule_next_task(self):
        try:
            function = self.iterator.next()
            deferred = function()
            deferred.addCallbacks(self.callback, self.errback)
        except StopIteration:
            self.scan_complete()

    def start_scan(self):
        self.schedule_next_task()

    def scan_complete(self):
        print "Scan of %s is complete" % self.address
        self.pp.pprint(self.context)

        # In this contrived example, we'll stop the reactor when we've finished scanning a host
        reactor.stop()

if __name__ == '__main__':
    import sys
    from optparse import OptionParser
    parser = OptionParser()
    parser.add_option("-u", "--username", dest="username")
    parser.add_option("-p", "--password", dest="password")

    (options, args) = parser.parse_args()

    address = args.pop(0)
    credentials = iter([SSHCredentials(options.username, options.password, None)])

    scanner = PlesiochronousHostScanner(address, credentials)

    reactor.callWhenRunning(scanner.start_scan)

    reactor.run()

It works:

satellite:~ clay$ python pleisio.py -u username -p password 10.20.30.40
Scan of 10.20.30.40 is complete
{'bios': {'bios_date': '11/15/2007',
          'bios_vendor': 'Sun Microsystems',
          'bios_version': 'S39_3B25'},
 'device': {'system_product': 'Sun Fire X2200 M2',
            'system_serial': '0805QAT0EA',
            'system_uuid': 'bd6529dc-fc79-0010-9e1b-001b245c1d4f',
            'system_vendor': 'Sun Microsystems',
            'system_version': 'Rev 50'},
 'hostid': '0ec2daa6',
 'installed_memory_in_MB': 32768,
 'interfaces': {'bge0': {'ipv4_addresses': [10.20.30.40],
                         'ipv6_addresses': [],
                         'mac_address': 00:1B:24:5C:18:B5,
                         'zone': None},
                'lo0': {'ipv4_addresses': [],
                        'ipv6_addresses': [],
                        'mac_address': None,
                        'zone': None}},
 'uname': 'SunOS myhost.mydomain.com 5.10 Generic_127112-11 i86pc i386 i86pc',
 'zonename': 'global',
 'zones': {'myzone': {'brand': 'native',
                          'ip_mode': 'shared',
                          'root': '/zones/myzone',
                          'state': 'running',
                          'uuid': '09fbf9ba-c0c5-408f-c9e9-820471983f25',
                          'zonename': 'myzone'}}}

The beauty of this approach is that the PlesiochronousHostScanner#scanning_sequence method is pretty straightforward, and could actually be written by end users familiar with Python but not familiar with asynchronous programming. It also makes discovery logic much easier to understand than in the state-machine-based asynchronous discovery engine I had previously built.

Having just concocted this tonight, I’m not sure whether this is something I’ll pursue, but it has been a fun experiment. I’m curious what other asynchronous programmers think of this approach.

SOAP support, which ought to be fully baked in Ruby by now, is still somewhat painful to work with. In Perl, SOAP just works. When I wrote our release orchestration tool a year ago, it took way longer than it should have to get Ruby talking to the SOAP iControl interface on our BigIP load balancers. By contrast, it took all of five minutes to get the Perl sample working — and that includes time spent installing the SOAP::Lite CPAN module.

Using Rails for the first time in a recent project, I was immediately struck by how little work is required to get a web app off the ground. I almost felt guilty for writing so little code. But a lot of the clever Rails magic that’s supposed to make life easier, didn’t. While error messages like, “Expected foo.rb to define Foo” seem pretty straight-forward, they are maddening when foo.rb does indeed define Foo. For their next trick, the Rails developers ought to use their meta-programming fu to produce intelligible error messages!

We recently ported a Rails app to JRuby, and straight away we ran into bugs. JRuby couldn’t call Java correctly, and it had a file descriptor leak in Net::SSH that caused the site crawler component of our application to go belly-up after a few hours. And we should have known better than to try talking to Oracle from JRuby on Rails. The activerecord-jdbc-adapter component had myriad issues — goofy things like "uninitialized constant ActiveRecord::VERSION", improper column name quoting, and incorrect integer datatype coercions. Finally we gave up and ported the database to MySQL.

I understand that Ruby and its libraries are open-source efforts written mostly by unpaid enthusiasts, so I try not to get too upset when things don’t work correctly. I wish I had the time to jump in and submit patches to fix issues when I run into them.

While I’m disappointed not to have won, I’m encouraged to see that our approaches were remarkably similar. We both wrote custom EFI CSM drivers to emulate the BIOS functions Windows requires to boot. I’m very curious how they managed to get VGA working, and I won’t be surprised if it doesn’t work in either the Mini or the Macbook Pro, as it looks like they did all their development on an iMac.

If nothing else, this was a tremendous learning experience for me, and the timing couldn’t have been better. I have recently become interested in Intel assembly and protected mode programming, topics I considered too challenging years ago when I was doing DOS programming, but concepts that make much more sense to me now. I had randomly dusted off some old assembly language references from my bookshelf and read some chapters on protected mode programming a few weeks prior to beginning work on this project, so I was able to grasp what needed to be done to provide a working solution almost immediately.

With the deadline fast approaching and narf’s Flickr images haunting me, I coded quickly and didn’t spend much time making the code pretty or maintainable, but I’m still fairly proud of the code I wrote. It’s fairly succinct, but does quite a bit. Anyone who’s interested can peruse the code here.

The main function is in OSXP.c, which contains code for reading the GPT partition table that Mac OS X uses, writing a MBR partition table that Windows would use, and loading a bootloader from an El Torito bootable CD-ROM.

Code to switch from protected mode to real mode (called a thunk) is in thunk.c and asmthunk.s. It’s not very general, but it’s the first protected mode assembly code I’ve ever written, and, surprisingly enough, it works.

Code to setup a real-mode interrupt vector table and the real-mode interrupt service routine is in rmisr.s. For the most part, this duplicates the thunk code, but in reverse order: it switches from real mode to protected mode and then back again. This reverse thunk is necessary to emulate BIOS functions using the native EFI functions (read disk sector, print character, etc).

The protected-mode interrupt service routine, which does the actual BIOS emulation, is in pmisr.c. It reads and writes a saved register context on the stack that the real-mode code inherits upon return from the interrupt service routine.

Just writing those thunk and interrupt service routines is probably about 50% of a complete solution, and I’m very happy with how they came out. The first time I thunked into the MBR code, it worked better than I expected, and actually identified the active partition, loaded the boot sector from it, and jumped to it. Booting into the CD bootloader worked also, though it hung right after probing memory.

I’m pretty amazed that my code works, but to toot my own horn a little more, I’m pretty happy with some of the debug techniques I came up with along the way. Running EFI applications in the pre-boot environment leaves a lot to be desired. You can’t exactly fire up gdb and throw a bunch of watchpoints on your code to find out what’s going wrong (though I did toy with the idea of compiling GDB for EFI). And even if I had a debugger at my disposal, it’s hard to debug a protected mode/real mode transition.

At first, my debugging consisted of writing copious amounts of debug output to the console and waiting for my tester, Chris, to run the code and take a picture of the result. At that time I didn’t have an Intel Mac to play with, so needless to say, progress was slow. We did get fairly far with this method, though. I wrote all of the partition table (GPT and MBR) code without ever having seen my code run with my own eyes. Chris’ pictures showed me what I needed to know, then I’d make a change, recompile, and Chris would download the new file and reboot. Again and again. Thanks, Chris.

I was unsure of how to access the CD-ROM under EFI, because it didn’t show up when I listed all the block I/O devices in Chris’ Macbook Pro. Ryan was nice enough to lend me his shiny new Mac Mini, and I was pleased to find that the CD-ROM device showed up once there was a disk in the drive. I was even more pleased to see that my El Torito code worked almost flawlessly from the beginning.

Then came the hard part, thunking into real mode. I wrote code and pored over it for hours making sure it looked right, but when I ran it, the computer spontaneously rebooted. Unsure of which instruction(s) were causing the reboots, I added an infinite loop to a section of the code, recompiled, and ran it. The machine hung. That validated that all of the code above the loop was not causing the reboot (at least not directly), so I moved the loop down a few instructions and tried again. Using this technique I was eventually able to find all of the bugs in my code, which were all stupid syntax problems and not logic problems (there’s a big difference between $0×10 and 0×10 in AT&T assembly).

Once the thunk and interrupt handler code was working, I started looking into why NTLDR was hanging after probing memory. NTLDR is 233kb and its disassembly is 97k lines long. I knew roughly where the hang occurred, based on the output I had from the last BIOS interrupt it invoked, but I wanted to narrow it down to a specific routine.

It occured to me that I could just write my own debugger of sorts. By handling interrupt 3, my code would get control anytime the NTLDR code stumbled onto an INT3 instruction. So, using the disassembly listing as a guide, I made a list of instructions that I thought might be interesting stopping points, and wrote a routine to replace those instructions with 0xCC (the INT3 opcode). Then I wrote an INT3 handler that replaced the original instruction and decremented the return address by one so the original code would be run upon return from the interrupt service routine. And, to my surprise, it worked!

Earlier today I extended this a bit by automatically enabling trap mode in the INT3 handler so I could repatch the breakpoint instruction with 0xCC right after executing the original code. This change allowed a breakpoint to show up each time through a loop or each time a particular function was called. Then I went a step farther and added a breakpoint option that would leave trap mode enabled, so I could get a trace of every instruction executed between two points in the code. This would prove useful for figuring out which branches the program took as it made various tests and decisions.

The one thing that continues to elude me is how to enable VGA text mode. The standard graphics and text framebuffers (0xA0000 and 0xB8000) aren’t even mapped in memory, and reading from the VGA registers appears to return garbage. I suspect if I knew more about PCI programming, I’d be able to map the framebuffer memory and configure the I/O ports, but I’m at a loss for how to do that. In the interim, I’ve been patching NTLDR at load time so that it writes to my own text framebuffer, which I then scan on every interrupt in order to paint a portion of the emulated textmode screen. This is slow and hackish, and I know it’s possible to enable true VGA mode (narf and blanka did), but I don’t know where to begin.

All in all I’m pretty happy with the code I wrote, even though I didn’t win the contest. I’m looking forward to the next big challenge and an opportunity to use some of the techniques I learned on this project.

During the holiday break I figured I’d learn some PowerPC (PPC) assembly while I still had the chance, given Apple’s decision to move to x86 early next year. Debugging simple programs isn’t much fun, though, so I figured I’d start poking around with a big application. An annoying thing kept happening everytime I fired up the app under the debugger, though; it exited immediately with a strange error code:

% gdb /Applications/blah.app/Contents/MacOS/blah
(gdb) run
Program exited with code 055.


Bummer. I remembered the same problem happening with that commercial Solaris app years before, but I never paid much attention to it back then, because it was possible to work around the problem by attaching to the program after it was already up and running. Apple seems to be a bit smarter than that, though, because whenever I attached to a running copy of the application, GDB seg faulted:

(gdb) attach 17813
Attaching to program: `/Applications/blah.app/Contents/MacOS/blah', process 17813.
Segmentation fault


Since I wanted to know why the application was exiting, I figured I’d step through it one instruction at a time until I found the culprit.

In simple programs, it’s usually sufficient to set a breakpoint on the main() function, but that skips over the C run-time start-up code. Since I wanted to step through each and every instruction in the program, including the start-up code, I used Apple’s otool command to print the application’s text segment, which gave me the address of the first instruction. I’ll demonstrate with /bin/ls:

[satellite:~] clay% otool -tvV /bin/ls | head -5
/bin/ls:
(__TEXT,__text) section
00001ac4 or r26,r1,r1
00001ac8 addi r1,r1,0xfffc
00001acc rlwinm r1,r1,0,0,26
00001ad0 li r0,0x0


This shows that the first instruction in /bin/ls is located at address 0×1ac4, so I set a breakpoint for that and started running the program. Again, using /bin/ls to demonstrate:

(gdb) break *0x1ac4
Breakpoint 1 at 0x1ac4
(gdb) run
Starting program: /bin/ls

Breakpoint 1, 0x00001ac4 in ?? ()


Now it helps to see the instruction that’s about to be executed, so I setup a display that prints the instruction at $pc (the program counter) everytime the program stops:

(gdb) display/i $pc
1: x/i $pc 0x1ac4: mr r26,r1


At first glance it may seem that GDB and otool print different instructions at address 0×1ac4:

otool:   or r26,r1,r1
GDB:     mr r26,r1

GDB is nice and prints user-friendly mnemonics like mr (for move register), which are easier to read and understand than the literal instructions that otool prints, but the instructions are identical.

Now the plan was to step over instruction after instruction, using stepi, until I found the offending bit of code. This was somewhat tedious, so I ended up using nexti quite a bit, which steps over function calls instead of stepping into them, speeding up the debugging. The only problem with that was that sometimes I would step over the function that caused the program to abort. Whenever that happened, I added a breakpoint on the address of the function call and then used stepi to step into the offending function. After several rounds of this (I think I was up to 11 breakpoints) I finally found where the program was stopping:

0x90054204 in ptrace ()
1: x/i $pc 0x90054204 <ptrace +36>: sc
(gdb) stepi
Program exited with code 055.


“sc” is the PPC instruction that invokes a system call. Since GDB is nice enough to print symbols when it can, I decided to see if ptrace is a documented system call in Darwin. Sure enough, it is:


PTRACE(2) BSD System Calls Manual PTRACE(2)

NAME
ptrace -- process tracing and debugging

SYNOPSIS
#include <sys/types.h>
#include <sys/ptrace.h>

int
ptrace(int request, pid_t pid, caddr_t addr, int data);

DESCRIPTION
ptrace() provides tracing and debugging facilities.


Well that sounds interesting, since I was having trouble debugging the process, and the process is calling this system call that provides some type of debugging facility. The man page describes how a debugger (like GDB) might use ptrace() to control another process, but that wasn’t what I was interested in. I was looking for a way a debugged program might be able to control the debugger. Reading on, the man page hinted that this might be possible:


[...] except for one special case noted below, all ptrace() calls are made by the tracing process [...]


Hmm, does that one special case allow a traced process to invoke ptrace() to control a debugger? Sure enough, it does:


PT_DENY_ATTACH

This request is the other operation used by the traced process; it allows a process that is not currently being traced to deny future traces by its parent. All other arguments are ignored. If the process is currently being traced, it will exit with the exit status of ENOTSUP; otherwise, it sets a flag that denies future traces. An attempt by the parent to trace a process which has set this flag will result in a segmentation violation in the parent.


Bingo! This explains both the seg fault and the exit immediately after startup. So now that I knew why the program wasn’t cooperating with GDB, I could coerce it into playing nicely. First, a disassembly of the ptrace() function:

(gdb) disas
Dump of assembler code for function ptrace:
0x900541e0 <ptrace +0>: li r7,0
0x900541e4 <ptrace +4>: mflr r0
0x900541e8 <ptrace +8>: bcl- 20,4*cr7+so,0x900541ec <ptrace +12>
0x900541ec <ptrace +12>: mflr r8
0x900541f0 <ptrace +16>: mtlr r0
0x900541f4 <ptrace +20>: addis r8,r8,4091
0x900541f8 <ptrace +24>: lwz r8,7860(r8)
0x900541fc <ptrace +28>: stw r7,0(r8)
0x90054200 <ptrace +32>: li r0,26
0x90054204 <ptrace +36>: sc
0x90054208 <ptrace +40>: b 0x90054210 <ptrace +48>
0x9005420c <ptrace +44>: b 0x90054230 <ptrace +80>
0x90054210 <ptrace +48>: mflr r0
0x90054214 <ptrace +52>: bcl- 20,4*cr7+so,0x90054218 <ptrace +56>
0x90054218 <ptrace +56>: mflr r12
0x9005421c <ptrace +60>: mtlr r0
0x90054220 <ptrace +64>: addis r12,r12,4091
0x90054224 <ptrace +68>: lwz r12,7792(r12)
0x90054228 <ptrace +72>: mtctr r12
0x9005422c <ptrace +76>: bctr
0x90054230 <ptrace +80>: blr
End of assembler dump.


Now I don’t know exactly what all of that means, but I saw the “sc” instruction in the middle of the function and I knew I wanted to avoid making that system call. The obvious thing to try was to set a breakpoint on function entry and then use the jump command to jump right to the last instruction in the function, effectively bypassing that pesky system call:

(gdb) break ptrace
Breakpoint 11 at 0x900541f4
(gdb) run
Starting program: /Applications/blah.app/Contents/MacOS/blah

Breakpoint 11, 0x900541f4 in ptrace ()
(gdb) jump *0x90054230
Continuing at 0x90054230.


When I did that, breakpoint 11 fired again, so I did the jump again, and breakpoint 11 fired again, so, well, the short story is that I had to do the jump 6 times before the program continued on. Maybe the developers were paranoid and called ptrace() six times. Whatever the reason, after finally getting past all six ptrace()s, the program started up just fine:

(gdb) jump *0x90054230
Continuing at 0x90054230.
Reading symbols for shared libraries . done

The program ran as normal, under control of the debugger. Now that I know how to get it to run under GDB I can start poking around with some of the more interesting bits of code.

I hope everyone’s having a nice holiday, and I promise to post more often!

Network administrators who maintain complicated Layer 2 networks should be very familiar with the operation of the Spanning Tree Protocol. One common point of confusion among administrators is the use of (essentially) arbitrary numbers to identify the current root bridge. While the root bridge identifier is deterministic, comprised of bridge priority and MAC address, it is not information that network administrators can use without consulting a reference that maps MAC addresses to human-friendly names.

Bridges and switches are often given hostnames for administrative purposes. The extension to Spanning Tree Protocol described below adds this user-friendly hostname information to the BPDU. The hostname could then be used by equipment vendors for diagnostic purposes, i.e., Cisco’s “show spantree” command.

The extensions described below are relative to ANSI/IEEE Std 802.1D, 1998 Edition. I believe these changes will not affect existing implementations of Spanning Tree Protocol, since the standard indicates that “any octets beyond Octet 35 are ignored”, and that “the Protocol Version Identifier is not checked on receipt, in order to allow the possibility of future specification of extensions to the Spanning Tree Protocol”. The extensions below would be detected by a compliant bridge implementation by checking the Protocol Version Identifier field of the BPDU.

This proposal was sent to the IEEE 802.1 committee on August 22, 2001. Initial response has been somewhat discouraging. The standards committee does not accept proposals from non-members, however becoming a member requires attending periodic meetings in Washington, DC. Without the means to attend these meetings, it is unlikely that this proposal will ever be considered. Perhaps an existing member of the committee will volunteer to represent this proposal in my stead…

Proposal

9.2.X Encoding of Bridge Names
[New section between "9.2.5 Encoding of Bridge Identifiers" and "9.2.6
Encoding of Root Path Cost"]

A Bridge Name shall be encoded as sixteen octets, taken to represent a
string of printable ASCII characters (octal 040 through 0177 [decimal 32
through 127]).  The string shall contain the first 16 characters of the
bridge's hostname, if configured, or any other string which might
uniquely identify the bridge.  This parameter is intended for human
consumption only.

The most significant octet is the first character of the string.  If the
intended ASCII string is less than sixteen characters in length, the
unused octets in the BPDU will be set to ASCII NUL (octal 0).  If the
intended string is greater than sixteen characters in length, any
additional characters will be truncated so that only the first sixteen
characters will appear in the BPDU.

9.3.1 Configuration BPDUs

Figure 9-1 will have the following data structure appended to the
diagram:

+-------------+
|             | 36
|             | 37
|             | 38
|             | 39
|             | 40
|             | 41
|             | 42
|   Bridge    | 43
|    Name     | 44
|             | 45
|             | 46
|             | 47
|             | 48
|             | 49
|             | 50
|             | 51
+-------------+

b) The Protocol Version Identifier is encoded in Octet 3 of the BPDU. It
takes the value 0000 0001.

That was the goal, at least.

The story starts with my first attempt to install Linux on SPARC hardware. I had purchased an old, retired Sun Sparc 20 workstation so I could tinker with Solaris at home. With 512 MB RAM and a quad-Ethernet card, it put my POS PC to shame. But I didn’t know it had two CPUs until I finally got bootp, tftp, and NFS working and was able to net-boot a Linux kernel on it. Twin penguins graced my 20″ Sun monitor (sounds small in the LCD era, but for a CRT this thing was massive!) — one for each of the CPUs.

Years later, I was working with a company that used primarily Sun hardware, and I had the opportunity to install some four-way E450s for a new project. When they arrived, we still had a few weeks before we had to turn the machines over to the developers, so I decided to experiment again with SPARC Linux. The installation this time around was much easier, and, as expected, four handsome penguins saluted me at boot!

About this time, the Sun Enterprise 10000 (or e10k) was considered a pretty beefy server: a fully-populated machine with 16 system boards sported 64 CPUs, 64 Ethernet interfaces, and 64 GB RAM — why anybody needed 64 Ethernet interfaces is beyond me. Against our advice, our development organization purchased two e10ks for use as Java application servers. So, we carved out a chunk of space in the datacenter and Sun rolled these twin behemoths in.

I was helping the developers figure out how to carve the machine up into 4-CPU chunks (called domains), so I had a good idea of the project timelines. When I learned the machines would sit idle for a few weeks before they were needed, I realized this was the opportunity of a lifetime — a chance to build and boot my own army of 64 penguins!

Carl Raffa, one of the brightest and most interesting people I’ve ever had the pleasure of working with, was eager to help. I don’t remember now how long it took to get Linux booting on the e10k. We first tried booting a fully-populated machine with 16 domains, but when that failed, we decided to try it with Solaris and discovered some hardware problems. After swapping some system boards around, we were able to boot Solaris.

Then it was back to trying to boot Linux. I don’t remember now what all of the problems were — most were simple 64-bit or endianness issues — or how long it took before we could consistently boot a single-domain e10k. But once we got that working, we progressively configured the machine larger and larger until we approached a fully-populated 16 domains. When we got to 48 processors, CNET picked up the story. I don’t know for certain, but I suspect that at that time, our e10k represented the largest (and most expensive) Linux machine ever booted.

We can’t take any credit for the low-level device drivers that made any of this work possible. Most of that support was implemented by people who didn’t have access to the big iron, so our involvement was really as tinkerers and testers more than innovators. That said, it was still a fun and challenging project.

Sadly, we were never able to test with a fully-populated e10k. While we were at lunch for a coworker’s retirement party the Friday before we had to turn the machines over to the developers, Sun Professional Services reconfigured the machine and blew away our playground.

As fate would have it, the e10k doesn’t have a framebuffer — its only console output is emulated via the service processor, a separate microcontroller in the e10k chassis. So even though I was never able to see my army of 48 penguins (much less 64), I know they were there, and that will have to do.