Kebe Says - Dan McDonald's Blog

I just finished a chat with a person who's doing a device driver, and he was worried that a certain header file wasn't available in his /usr/include. This struck me as odd, as I always get my headers from the workspace's proto area...

Then I realized I've had 15 years at Sun under my belt and this person's a complete newbie.

I haven't looked very closely at the Illumos build instructions, but I'm going to do some things now that will help kernel module writers (e.g. device drivers) get started without resorting to a full build right off the bat. I'll assume that you've installed the appropriate compilers and the "onbld" package so that you have a populated /opt/onbld/bin.

STEP 1: The /opt/onbld/bin/ws command:

When you go to work in an Illumos source base, your best off "entering it" via the ws command. I've hacked my .tcshrc to print a different prompt when I'm in with ws. Here, check it out:

everywhere(~)[1]% ws ws/to_mhi

Workspace                    : /export/home/danmcd/ws/to_mhi
Workspace Parent             : /export/home/danmcd/ws/illumos-clone
Proto area ($ROOT)           : /export/home/danmcd/ws/to_mhi/proto/root_i386
Parent proto area ($PARENT_ROOT) : /export/home/danmcd/ws/illumos-clone/proto/root_i386
Root of source ($SRC)        : /export/home/danmcd/ws/to_mhi/usr/src
Root of test source ($TSRC)  : /export/home/danmcd/ws/to_mhi/usr/ontest
Current directory ($PWD)     : /export/home/danmcd/ws/to_mhi

WS-everywhere-WS(~/ws/to_mhi)[0]% 

You'll notice a few things got set in the environment. What I use to alter my .tcshrc is the CODEMGR_WS variable. You should do the same in your favorite shell's config.

UPDATE: You will need to set SPRO_ROOT and BUILD_TOOLS after invoking ws. I do this already in my .tcshrc, but forgot to report it. A newer tool: bldenv, fixes this, but currently at the cost of a configuration file. There's talk of merging ws's simplicity with bldenv's completeness.

One of the key concepts in building Illumos is the "proto area". This is a version of the root filesystem that lives within your source tree. You'll see it set above. There's one per basic architecture type (i386 or sparc). When a full "nightly" build happens, the proto area gets populated with headers, libraries, commands, kernel modules, etc., and then the packaging tools sweep up their input from the proto area. The proto area contains more than what is on a running system.

You need to populate your proto area with basics (directory structures, etc.) to start.

WS-everywhere-WS(~/ws/to_mhi)[1]% cd $SRC
WS-everywhere-WS(usr/src)[0]% pwd
/export/home/danmcd/ws/to_mhi/usr/src
WS-everywhere-WS(usr/src)[0]% dmake sgs
       < Go get a drink of water or coffee, it's gonna be a bit... >
WS-everywhere-WS(usr/src)[1]% 

The "sgs" target sets up the proto area completely.

If you're proceeding to build, say, kernel modules, you should populate the kernel include files in the proto area.

WS-everywhere-WS(~/ws/to_mhi)[0]% cd usr/src/uts
WS-everywhere-WS(src/uts)[0]% dmake install_h
    < TONS of output deleted... >
WS-everywhere-WS(src/uts)[0]% 

UPDATE Fellow Illumos hacker Rich Lowe has informed me that "dmake setup" does both sgs and install_h in one fell swoop.

And then you can go and compile your kernel module. I'll use "ip" as an example:

WS-everywhere-WS(src/uts)[1]% cd intel/ip
WS-everywhere-WS(intel/ip)[0]% pwd
/export/home/danmcd/ws/to_mhi/usr/src/uts/intel/ip
WS-everywhere-WS(intel/ip)[0]% dmake
     < MORE output deleted... >
WS-everywhere-WS(intel/ip)[0]% 

If you want to lint-check your module, don't do the obvious "make lint" but instead do "make modlintlib". This will perform basic lint sanity without the overhead of a full crosscheck.

Now if you want to do something in userland, you'll need to do more than a simple header install. You MIGHT need to bringup libraries too, because it's possible your workspace's libraries have different versions than the machine you're actually building on.

WS-everywhere-WS(intel/ip)[0]% cd $SRC/lib
WS-everywhere-WS(src/lib)[0]% 

If you utter "dmake install", it's going to be a while. You can, if you know only a certain library was altered, cd into that library and utter "dmake install" in there. For example:

WS-everywhere-WS(src/lib)[0]% cd libipsecutil
WS-everywhere-WS(lib/libipsecutil)[0]% dmake install_h
     < output deleted... >
WS-everywhere-WS(lib/libipsecutil)[0]% dmake install
     < MORE output deleted... >
WS-everywhere-WS(lib/libipsecutil)[0]% 

Then you can go to, say, your new command, and start compiling and debugging there. Once you're done, you can exit this shell, and it will return you to your original pre-ws shell.

Hopefully this will lower some of the barriers to entry for budding Illumos hackers.

I think I've managed to move all of my old blog entries over from blogs.sun.com. Hopefully I'll be posting some Illumos-related technical content before too long. Stay tuned!

At Wendy's and Garrett's advice, I've set up shop here on Blogger/Blogspot.

I plan on importing all of my old Sun blog posts here, but I exported in a non-blogger non-XML (ick) format. So I'll be backpatching by copy-and-paste when time allows.

Happy blog reading, you half-dozen readers! :)

David Reed passed along a pointer to this paper by Dan Geer:

A Time for Choosing

Please read it, and understand the founding spirit of the Internet. And with that, I say goodbye to Oracle.

15 years ago I was finishing up last-minute changes at NRL while getting ready to move coasts. While I'm not moving coasts, I'm at the point where I'm finishing up last-minute changes again.

I'm leaving Oracle this week, and will be trying something a bit different after that. I've been doing IPsec or at least TCP/IP related work for the entirety of my time at Sun. I expect to be back in TCP/IP-land relatively soon, but I will be learning some new-to-me technologies in the immediate future.

I've met and worked with some extraordinary people during my time at Sun. I hope to keep in touch with them after I depart. If any of you half-dozen readers wish to keep up, I'd suggest following my Twitter feed until I decide whether or not I find a new home for this blog. I'm also findable on Facebook and LinkedIn for those so inclined.

Hello again!

Kenny Paterson's once again turning the theoretical into practical. This time he's pointed out that if one configures IPsec to MAC-then-encrypt (do packet authentication first, THEN encrypt the packet), one is open to cryptographic attack. Here's a citation for his ACM CCS paper.

The good news is that we cannot configure the IPsec SPD to perform MAC-then-encrypt at all. One could configure transport mode to just MAC, then have the packet transit a tunnel that just encrypts, but then you'll see warnings about the encryption-only tunnel configuration. This has been true for a LONG time (starting with S9, maybe even S8).

So basically, we don't make it easy for you to shoot yourself in the foot this way. You really have to try, and as I pointed out earlier, the encryption-only part will warn you.

My birthday is upon me.

My birthday present was an iPhone 4. Yeah, I got it early, but it was nice to have for my just-finished vacation drive. I noticed that when I'd reshuffle the 1763 songs on there, I'd more often than not hit a collision with a song I swear I'd heard during the previous shuffling. Time for some math...

The Birthday Problem (or Birthday Paradox, not because it's a real paradox, but because it's counterintuitive) shows that it only takes 23 people to be in the same room before the chances that two of them share a birthday are equivalent to a coin flip. The link above shows how one derives this. Basically, as you keep adding people, the probability of there NOT being a shared birthday decreases. That probability hits near-enough to 50% at 23 people.

I figured if I would have listened/remembered 30 songs from a previous shuffle. That's 2-3 hours of music, not a lot when you're driving all day. So if I accidentally shook my iPhone and reshuffled the songs, how many would I need to hear until I had a coinflip's chance of hearing a repeat from the previous 30?

Basically, the probability of NOT hearing a previously-heard song was (1763-30) / 1763. If that wasn't a repeat, the probability of another non-collision would be (1762 - 30) / 1762. Note that unlike the birthday problem, I'm decrementing the denominator as well. This is because I'm not going to hear the same song twice in a random shuffle.

I wrote a C program (because I hack way too much ON code) to compute things. Here it is:

#include <stdio.h>

int
main(int argc, char *argv[])
{
        double p;
        int i, listened, total, tries;

        if (argc != 4) {
                fprintf(stderr,
                    "usage:  ipod [listened-songs] [total-songs] [tries]\n");
                return (1);
        }

        p = 1.0;
        listened = atoi(argv[1]);
        total = atoi(argv[2]);
        tries = atoi(argv[3]);

        for (i = 0; i < tries; i++)
                p *= (double)(total - listened - i) / (double)(total - i);

        printf("P(NO repeat for %d on the second playthough): %lf%%\n", tries,
            p * 100.0);
        printf("P(Repeat for %d on the second playthough): %lf%%\n", tries,
            (1 - p) * 100.0);
        return (0);
}

Turns out, I need to hear 40 songs to have a coinflip's chance of hearing one of the previous 30 songs I heard before reshuffling the 1763 total songs.

mactavish(~/sources)[0]% ./a.out 30 1763 40
P(NO repeat for 40 on the second playthough): 49.942794%
P(Repeat for 40 on the second playthough): 50.057206%
mactavish(~/sources)[0]% 

The above program should work for any sized iPod/iPhone collection, or any sized song-memory/patience. I really hope I got the math/derivation right. Any probability wizards in the audience can feel free to school me in the comments section.

Hello you half-dozen readers!

Recently I reinstalled my home server to OpenSolaris, build 130. I used zfs send and zfs recv to recover my relevant bits of data. I also constructed new zones, this time using ipkg zones.

Using ipkg zones takes a bit of acclimation. The biggest thing to note is that if you need a specific software package, you have to use pkg install in the zone you wish to have the software. For example, I have three zones:

• The Global, internal-only, server zone - My global zone spends most of its time without a default route, serving NFSv4 and anything else I can think of only to my local LAN. If I need a new service, I temporarily add a global route, and pkg install away.
• The Webserver zone - Just like it says. I needed Apache here, and had to pkg install Apache here.
• The Router/NAT/IPsec-remote-access/Firewall zone - If you're going to put potential targets on the Internet, why put the global zone there? Especially with Crossbow VNICs and IP Instances!

So I got all of these zones, and the global zone isn't even net-attached most of the time? More interesting still, I need to upgrade all of these zones.

I posed this problem to pkg-discuss@opensolaris.org. Right now, pkg image-update won't upgrade the non-global zones. Worse still, I need to upgrade a zone that's also acting as my NAT and router. Luckily for me, Ed Pilatowicz gave me some good advice: i do have one other workaround/suggestion you could try. after you do
an image-update of your global zone. before rebooting, use beadm to
mount the new image on /a. then you can try doing "pkg -R
/a/path_to_your_zone/root image-update" for each of your zones. this
will probably work as long as your always image-update'ing to the latest
bits in the repository (and no new images get pushed to the repository
in between all the image-update opreations.) So I took Ed at his word.

Even if you have an ultra-paranoid global zone, you need to get it talking to an IPS repository. Either temporarily add an off-link route like I do, or have a local repository handy. Proceed and pkg image-update your global zone. Make sure you use --be-name to pick a BE name that you'll remember.

Next, you literally beadm mount new-be-name /mnt and for each zone root directory (while still able to reach the repository from your global zone) do pkg -R zone-root-path image-update. For my own example, I did:

• pkg image-update --be-name 132
• beadm mount 132 /mnt
• pkg -R /mnt/export/home/webserver/root image-update
• pkg -R /mnt/export/home/router/root image-update
• beadm umount 132
• reboot

This worked quite well for me moving up from 130 to 132. Just make sure your global zone can reach the repository, and you should be golden.

In all honesty, I'm glad this regulatory dance is over. We've all been having a little itch in our brains about this. Even if any of us have had real work to do, we've been at least a little distracted by by this whole acquisition uncertainty.

Well, we're finally part of Oracle now, and I think that's pretty cool. Larry E. wants to butt heads with IBM and HP directly, and quite honestly, we at Sun have been doing that on-and-off for at least my not-quite-14-years here. Now that this uncertainty has been removed, we can at least narrow the uncertainty to any internal-to-Oracle decisions, which given certain statements both in the past and yesterday seem pretty encouraging, at least from my engineering perspective.

Jonathan said we should light a candle for Sun. As a prank gift for my 40th birthday, I got a 40-ounce bottle of Olde English. I think instead I will pour that 40 for Sun.

My wife is the "cookie mom" for our twin girls who are in Daisy Scouts. She was very surprised when she logged in to the regional Girl Scouts cookie site (URL withheld in case any rabid fanboys do something stupid), and discovered that apparently, she needs to use Windows and Internet Explorer.

Their user documentation says: "We do not provide Mac support," and "Use any (non-Mac) computer at home or at work or at the local library." Does this mean they support OpenSolaris, Linux, or *BSD? Naaah, didn't think so.

We're a no-Windows household. We have three Macs, one work-issued OpenSolaris laptop, and a homebuilt OpenSolaris server. Especially in this age of people understanding vendor lock-in as a Bad Idea (TM), I'm shocked and appalled.

I'm going to forward this to a few Mac sites, and maybe slashdot. I'm sure nothing's going to change, but at least this should be discussed a bit, no?