fidzu : kernel

It is something I have done many times under many different operating systems. You write something into the startup scripts, take the system down, then regain control at startup. So I planned to take this approach for my KVM-based rcutorture setup: Mount the image file, deposit a test script in the startup scripts, unmount the image file, start qemu, then analyze the results (either deposited in the filesystem or dumped to the console). What could be easier?

So I manually mounted the file I use as the qemu disk image, my plan being to manually create simple tests as a first step towards automation.

Hmmm... Everything looks very strange and unfamiliar. Ah, yes, this is upstart. No problem, the Internet is but a mouse-click away, right? But wait, the documentation says that upstart and the more-familiar (to old guys like myself, anyway) sysvinit can co-exist on the same system. And what about this new systemd thing that I keep hearing about?

So my tests are going to have to inspect the filesystem and figure out which of these three things is installed. And maybe someone installed one of them, then switched to the other, leaving traces of their earlier choice lying around. How is my script supposed to figure all that out? Of course, if it was just me running the tests, I could simply make sure that a pre-selected boot-up mechanism was installed. But that is silly - anyone anywhere should be able to test RCU. So I need to be able to deal with any of the three boot-up mechanisms. But wait, it is far worse than that: What is my script supposed to do when someone else comes up with a fourth, fifth, or sixth boot-up mechanism? Ouch!!!

It is clearly time to just say "no"! After all, my main test (rcutorture) is coded in the kernel, so it is clearly going to be far easier to translate my driver scripts to Linux kernel code than to code up a script that can outwit all present and future perpetrators of bootup mechanisms. In-kernel coding will allow me to fully control the test using kernel boot parameters, and thus happily ignore which of sysvinit, upstart, systemd, or whatever is installed. Some times you just have to get a horse!

11 Nov 2011 6:12pm GMT

Chris Siebenmann mentioned in e-mail to me that a new terminal window opens if one Ctrl-clicks on it in Activities in GNOME 3 (there are more tips in comments of his blog post). Previously, I found that right-click there brings up a menu that can open new windows, but this takes it to the new level. Owen Taylor, you are so devious!

Back in 1985 or so, a company where I worked obtained a very expensive and unique piece of equipment: an IBM PC with a hard drive. Someone installed a game on it, called "Leisure Suit Larry" one or the other, and the office took turns playing it. The game was a quest with "quasi-natural" command input. At some point in the game, the player has a dull knife that does not cut. Someone heard from someone that it needs to get sharpened, but nothing we tried worked. Nobody in the firm knew English, so I remember trying "make knife sharp", "knife sharp", "sharp knife", and any other permutation including "knife sharp do". The right answer was "sharpen knife".

GNOME 3 reminds me of that quest. Random inputs that make complete sense to Owen, same as the conjugation into imperative made complete sense to an English speaker, but entirely opaque and mysterious to people who are not in on the secret.

10 Nov 2011 7:16pm GMT

This is mostly for my own reference, but since it might be useful to others:

By "Properly booting" I mean "Integrating into the boot system as well as Mac OS X does". The device should be visible from the boot picker menu and should be selectable as a startup disk. For this to happen the boot should be in HFS+ format and have the following files:

• /mach_kernel (can be empty)
• /System/Library/CoreServices/boot.efi (may be booted, if so should be a symlink to the actual bootloader)
• /System/Library/CoreServices/SystemVersion.plist which should look something like

  <xml version="1.0" encoding="UTF-8"?>
  <plist version="1.0">
  <dict>
          <key>ProductBuildVersion</key>
          <string></string>
          <key>ProductName</key>
          <string>Linux</string>
          <key>ProductVersion</key>
          <string>Fedora 16</string>
  </dict>
  </plist>
  

That's enough to get it to appear in the startup disk boot pane. Getting it in the boot picker requires it to be blessed. You probably also want a .VolumeIcon.icns in / in order to get an appropriate icon.

Now all I need is an aesthetically appealing boot loader.

comments

09 Nov 2011 10:06pm GMT