Andrea Arcangeli [interview] offered a tiny Python script called KLive for tracking kernel usage. He explained, "during the Kernel Summit somebody raised the point that it's not clear how much testing each rc/pre/git kernel gets before the final release." The simple script is a proof of concept, and is designed to be started at boot time. It collects a small amount of information about your computer (kernel version, amount of RAM, number of CPUs, speed in megahertz, and number of devices) and routinely sends this data to a central server. The collected data is then displayed in a simple chart, with the hope that it provides a useful estimate as to how much testing each kernel is getting.
Running Andrea's KLive script requires the Twisted Python networking framework. Once installed, you simply execute "twistd -oy klive.tac" and the script begins running in the background. Ideally the script would be launched automatically at boot time. Andrea noted, "I setup a server to track automatically the amount of testing that each kernel gets. Clearly this will be a very rough approximation and it can't be reliable, but perhaps it'll be useful." He went on to note that if the project was considered useful, it might make sense to get rid of the userland script and move everything into the kernel, making it a configurable option to simplify use. He adds, "if this won't be useful, the time I spent on it is very minor so no problem ;)."
From: Andrea Arcangeli [email blocked] To: linux-kernel Subject: KLive: Linux Kernel Live Usage Monitor Date: Tue, 30 Aug 2005 05:09:59 +0200 Hello, During the Kernel Summit somebody raised the point that it's not clear how much testing each rc/pre/git kernel gets before the final release. So I setup a server to track automatically the amount of testing that each kernel gets. Clearly this will be a very rough approximation and it can't be reliable, but perhaps it'll be useful. If this won't be useful, the time I spent on it is very minor so no problem ;). All the details can be found in the project website: http://klive.cpushare.com/ Full source (server included) is here: http://klive.cpushare.com/downloads/klive-0.0.tar.bz2 To run the client: wget http://klive.cpushare.com/klive.tac Then at every boot (like in /etc/init.d/boot.local): twistd -oy klive.tac In theory we could get rid of the client entirely and make it a kernel config option, but I've no idea if this project is useful, so I don't want to spend too much time on it at this point. Thank you.
Into the kernel?
You often hear agruments that X and Y don't belong in the kernel.
It was one of the reasons for removing devfs, for example...
So why put _THIS_ in? It's fine as a userland script...
Use the kernel as a distribution vector only
You could make it a userland process that's distributed with the kernel. After all, things like menuconfig, ksymoops and certain patch update scripts are all userland things distributed with the kernel.
A different interesting use of this sort of coverage tracking is that the kernel developers can maybe use it to determine what features are actually getting used, and which are just being carried around.
Distribute it with the kernel
I think Alan has a good suggestion:
Wrong way around - you need to let people turn it on. Perhaps distribute
it with the kernel so you can
make register
[Reports hardware, stashed a unique sha-1 hashed cookie]
[Asks for permission, installs UDP ping daemon]
make unregister
but it would have to be opt in. That might lower coverage but should
increase quality, especially id the id in the cookie can be put into
bugzilla reports, and the hardware reporting is done so it can be
machine processed (ie so you can ask stuff like 'reliability with Nvidia
IDE')
Right. But still this is a fe
Right. But still this is a feature I sure would not enable on my machine.
I havent installed the debian popularity contest stuff either btw.
But then there is the difference from free software to non-free: With other OSes you're not asked if you want such a feature ;-)
I guess it's testing kernels
I guess it's testing kernels only: rc kernels, maybe mm kernels. It's certainly bloat you wouldn't want in a real kernel but I suppose if it's not enabled in release kernels it's not so bad. The point is to measure how much testing is being done on this code...
I think it's relatively unfortunate that the current script requires both Python and the Twisted framework, just to report what kernel you're testing. Although it's not very tasteful I guess adding a reporting tool in the kernel could be the a reasonable, pragmatic solution.
What are you talking about? I
What are you talking about? I don't see anyone mention anything but python script!?
Great Idea!
I think this is a great idea. I think this will help "new" platforms such as x86_64, dual core, etc., get the better supprt. I've had several bugs in the past year or two that might havee been addressed faster if the developers had a better idea of what configurations were being run by linux users. I think that it can be a problem, that kernel developers underestimate the usage of various configurations. I would certainly participate, if nothing more than a way to "vote" and make sure that my hardware config get's counted and hopefully supported.
Duplicate effort ?
This looks a lot like LiSt (http://www.linux-stats.org/), which collect the same info and a bit more, with a very straightforward bash script.
It was originally gentoo-specific but not any more.
Also Linux Counter
The Linux Counter project also collects
kernel version statistics.
See
http://counter.li.org/reports/systemstats.php