public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [RFC] make it easy to test new kernels
@ 2006-01-25 22:30 jerome lacoste
  2006-01-25 22:50 ` Christopher Friesen
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: jerome lacoste @ 2006-01-25 22:30 UTC (permalink / raw)
  To: lkml

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFC] make it easy to test new kernels
  2006-01-25 22:30 [RFC] make it easy to test new kernels jerome lacoste
@ 2006-01-25 22:50 ` Christopher Friesen
  2006-01-25 23:02 ` Jesper Juhl
  2006-01-30 14:52 ` Tejun
  2 siblings, 0 replies; 4+ messages in thread
From: Christopher Friesen @ 2006-01-25 22:50 UTC (permalink / raw)
  To: jerome lacoste; +Cc: lkml

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFC] make it easy to test new kernels
  2006-01-25 22:30 [RFC] make it easy to test new kernels jerome lacoste
  2006-01-25 22:50 ` Christopher Friesen
@ 2006-01-25 23:02 ` Jesper Juhl
  2006-01-30 14:52 ` Tejun
  2 siblings, 0 replies; 4+ messages in thread
From: Jesper Juhl @ 2006-01-25 23:02 UTC (permalink / raw)
  To: jerome lacoste; +Cc: lkml

On 1/25/06, jerome lacoste <jerome.lacoste@gmail.com> 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 <jesper.juhl@gmail.com>
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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFC] make it easy to test new kernels
  2006-01-25 22:30 [RFC] make it easy to test new kernels jerome lacoste
  2006-01-25 22:50 ` Christopher Friesen
  2006-01-25 23:02 ` Jesper Juhl
@ 2006-01-30 14:52 ` Tejun
  2 siblings, 0 replies; 4+ messages in thread
From: Tejun @ 2006-01-30 14:52 UTC (permalink / raw)
  To: jerome lacoste; +Cc: lkml

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2006-01-30 14:52 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-01-25 22:30 [RFC] make it easy to test new kernels jerome lacoste
2006-01-25 22:50 ` Christopher Friesen
2006-01-25 23:02 ` Jesper Juhl
2006-01-30 14:52 ` Tejun

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox