You are viewing paulmck

Previous Entry | Next Entry

And it used to be so simple...

buggytux
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!

Tags:

Comments

paulmck
Dec. 15th, 2011 07:37 pm (UTC)
And I ended up doing both
For tests that I need anyone to be able to run anywhere on any Linux kernel with any userspace, there is really no alternative to driving the test from the kernel.

But for my own detailed RCU testing, for example, generating traces to verify that my change did what I thought it did, using the "init=" parameter to force a script to execute is really nice. I have a Linux partition in a file on my laptop, and have created a /etc/rcu directory for my RCU-test scripts. One caution: Because the normal init didn't run, these scripts get to do some extra work, like mounting debugfs.

So a big "thank you" for all the advice, both here, on Facebook, and on Google+!