Hi,
Linux user from a long time, I feel that I am not doing enough to help
Linux improve. In particular, I would like to test new Linux kernels
more often.
Unfortunately, as time pass buy, I have less and less time to play
with setting up my machines. I cannot spend time compiling and booting
a kernel for every machine I have access to, nor take the risk to
crash a machine I depend upon.
So although I have access to 5-10 machines easily, I end up testing
kernels on 2 machines only, 5-6 times per year per machine (i.e. for
each kernel release). The other machines for their distro specific
kernel upgrades (or test a live distro)...
The only machine I can play with daily is my desktop. But as a
developer, it takes me several minutes to go from a cold boot to a
desktop suitable for my work. I usually have many graphical
applications (browser, IDE, plenty of shells, IM tools), servers
(database, web server, ...). So I usually don't reboot my desktop for
weeks. (I really hope that software suspend will finally help me to
speed this up someday.)
I could compile a new kernel everyday. It's not too hard a process to
automate. But today, I cannot take the cost and risk of rebooting my
machine. It just takes too much time.
Now I am wondering if there's a way to solve this. How can we make the
testing of new kernels easier?
A kernel.org live distro with integrated issue reporting could be an
idea, but it wouldn't show particular desktop application breakage.
And I see a Gnome/KDE/XFCE flame war ready to start...
Now, will all these talks about virtualization, I wonder if it will be
possible one day to just download a new virtualized test OS and test
it without rebooting the main one. I could always allocate 10 G to a
test system on my disk. As long as I don't have to reboot.
But maybe I am focusing on the wrong approach?
Linux developers, what would be the thing that takes no more than 4-5
min per day that people like me could do with our machines to help you
improve Linux?
Jerome
jerome lacoste wrote:
> Now, will all these talks about virtualization, I wonder if it will be
> possible one day to just download a new virtualized test OS and test
> it without rebooting the main one. I could always allocate 10 G to a
> test system on my disk. As long as I don't have to reboot.
A large portion of kernel issues are found in the hardware support,
which is difficult to test in a virtualized environment.
However, something like this could ensure that the APIs handle random
garbage, that POSIX works properly, etc...
Chris
On 1/25/06, jerome lacoste <[email protected]> wrote:
[...]
>
> Now, will all these talks about virtualization, I wonder if it will be
> possible one day to just download a new virtualized test OS and test
> it without rebooting the main one. I could always allocate 10 G to a
> test system on my disk. As long as I don't have to reboot.
>
[...]
Sure, you can test some aspects of the kernel in a virtualized environment.
Setup Xen [1] or UML [2] (or some other virtual machine software like
Bochs [3] or Qemu [4]) and use those virtual environments for testing
your new kernels - no reboots required.
Not the best way to test all aspects of new kernels, but if reboots
are out of the question then they are certainly options and better
than no testing at all :)
1. http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
2. http://user-mode-linux.sourceforge.net/
3. http://bochs.sourceforge.net/
4. http://fabrice.bellard.free.fr/qemu/
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
jerome lacoste wrote:
>
> But maybe I am focusing on the wrong approach?
> Linux developers, what would be the thing that takes no more than 4-5
> min per day that people like me could do with our machines to help you
> improve Linux?
>
Hello, Jerome.
As you've noted earlier in the message, swsusp will be helpful, I think.
Here's my suggestion.
1. setup swsusp/swsusp2 on target machines (swsusp2 works pretty well)
2. setup small (10G maybe) test partition on target machines with
minimal distribution (just install on one machine and copy the partition
over)
3. setup netboot for target machines (reserve one machine for kernel
serving)
When a new kernel comes out...
1. build the kernel and set it up for netbooting
2. software suspend testing machines & reboot'em with the new kernel
using netbooting
3. see whether things work
4. reboot and resume production system
The suspend/resume instead of full rebooting should save a lot of time.
If you also use netbooting for the production kernel, you can just
change settings on the kernel serving machine to select which kernel to
boot and which partition to mount for root fs.
--
tejun