During the past month, I had to do all tmpfs development on my laptop. This includes coding and testing. If you have ever done any kernel hacking you know what this means: reboot every now and then to test your changes, which can drive you crazy after few reboots (specially if things keep breaking).
So when I got back home, the first thing I did was to set up a machine I had lying around for kernel testing exclusively. The machine is a Pentium 133Mhz with 32MB of RAM and a 3GB hard disk, more than enough for my purposes. (I'd have also used qemu... but since I had the hardware...)
Here are some details about its configuration, designed to minimize manual intervention:
- The machine is in headless mode. I.e., no monitor nor keyboard and connected to my development machine using a null serial cable. I did all the installation of NetBSD over the serial line. In order to connect to it, I use the tip(1) command.
- The machine uses GRUB (also configured to use the serial line) to load the development kernel from my server and boot it, all of this in an unattended manner. Note that GRUB has some problems loading modern NetBSD kernels: some of them can be avoided by tweaking the configuration file, but others can't.
- All services (e.g., sendmail, cron, inetd...) are disabled during startup to reduce boot time.
- getty(8) is configured to automatically log in the root user. This can be done through the al parameter in /etc/gettytab.
- root's ~/.profile fetches the new kernel again and installs it as /netbsd. Then, it asks me to press a key to run tmpfs regression tests afterward. (I made it require a key press to let me cancel the execution of tests if wanted.)
- The development machine, after successful builds, uploads new kernels to the server from which GRUB fetches them.
With this setup, whenever I have built a new kernel in my development machine, I can instantly reboot the testing machine, press RETURN when asked for it and see the results. No need to copy the kernel to the second box in any way nor to enter any command!
6 comments:
[Originally posted at 2005-08-05 11:33 am UTC]
May be you shuld peep at it. It's pretty easy add a new fs to the system and you only need to play with some structs LKM related, after the dev process is up you only need to integrate the code in the kernel.
Moveorer the docs about LKM in netbsd are very good.
Juanjo
[Originally posted at 2005-08-05 11:46 am UTC]
LKM support is something I'd like to implement, but not yet (mostly because this is something else I'll have to learn, and there are other things to be done before that).
Anyway, even if it was a module, that wouldn't avoid all the crashes I get, thus having to reboot anyway ;)
Thanks for your comments! (And glad to see you still around :-)
[Originally posted at 2005-08-05 01:41 pm UTC]
Of course... a bogus module will crash your comp, but I'm sure development process speeds a lot because you don't need to recompile the kernel (or part of it) and reboot.
Well, you now have a kewl development envirnoment, but poor guys like me stick on the LKM stuff :D (right know I'm playing with the VT8235 south bridge under obsd).
Juanjo
[Originally posted at 2005-08-05 05:51 pm UTC]
I have a xen domU running netbsd to test tmpfs. It is very easy to restart
the domain if crashes. Highly recomended.
[Originally posted at 2005-08-07 06:32 pm UTC]
You could combine your method with his tip: only recompile the kernel module (to reduce compile time) and sync that to your testing machine (to avoid crashes on your development machine).
GH
[Originally posted at 2005-08-07 09:00 pm UTC]
Yes, but recompiling the kernel is a quick operation if you have only modified a few files. I don't do full rebuilds; just cd into the kernel build directory and do a 'make'. Sure this can take a while on old machines, but luckily I have a powerful one :-)
Post a Comment