On Friday 08 February 2008, Chris Lamb wrote:
> These sorts of tests are useful when you have built a new machine and you
> wish to test the stability of the system, or you are experimenting with
> "overclocking" and/or esoteric cooling solutions.
>
> The basic idea is that shortcomings in the cooling, installation and the
> hardware itself are forced to appear at a predetermined stage, instead of
> arising at some inconvenient time in the future.
>
> Many system builders perform tests such as these after Debian has been
> installed, but it may be advantageous to perform it in the installer in
> order to prevent against filesystem corruption. It would also be
> significantly more convenient and allow integration with preseeding, etc.
As you indicate yourself, cpuburn can be dangerous. I do understand why it
would be attractive for experienced sysadmins responsible for commercial
installations to have this available, but we should be very careful with
this. Especially since users will not have manpages available.
I have the following questions that I'd like to see answered to so we can
form a more informed opinion on this.
Are all x86 processor types supported?
Are multiprocessor systems supported?
Will cpuburn work in emulators or virtual machines?
Is the program safe in the sense that if an incorrect processor type is
selected, it will error out? How are such errors handled?
If not, can processors be damaged if an incorrect CPU type is selected?
> Obviously, this should not be part of the main install process (!), but
> as an optional component.
Agreed. The udeb should not be loaded by default, but only when specifically
requested during the "load installer components" phase. It can then also be
loaded at boot time by passing "modules=cpuburn".
This means that its priority should be "optional".
Even then I'm not sure if this option should be in the normal flow of the
installation. It could be safer to have it listed after Finish install and
thus only executable if selected from the menu (i.e. have a menu number
greater than 90000 (see [1]).
I guess my opinion on that depends on answers to the questions I currently
have.
> My patch is in three parts:
> 3. Adds the cpuburn-udeb package (the interesting bit)
>
> The resulting udeb is approximately 3KiB. I have put some screenshots
> online here [0].
What are its dependencies? Please show the output of debc (of dpkg -I) for
the udeb.
Some comments on the patch.
- As the description will be shown in anna, I would suggest to change the
description to:
perform CPU stress test (burn in) - expert use only
- For the initial dialog I would suggest to add that users should carefully
read the cpuburn documentation before using it.
- I wonder if the CPU type could not be determined based on /proc/cpuinfo
and options/defaults adjusted accordingly (with an "unrecognized" error
dialog for unknown types); see for example [2]
- Some coding style comments (though not blocking):
- we prefer to have 'then' and 'do' on the same line as if/while as
it saves a few bytes
example: if true; then
- for case statements we use 4 spaces for the conditions as that saves
one level in the indentation of the conditional code and in most cases
also saves some bytes (spaces versus extra tab for each conditional
line)
> (Frans asked me to post the patch here instead of filing a wishlist bug
> against cpuburn. I believe Aurelien--the maintainer of cpuburn--reads
> this list anyway.)
Well, not _instead_, but rather _before_. Additions of new udebs need to be
approved by the D-I team before they will be accepted by FTP masters, so
discussing it here before filing the BR and maybe having the package
rejected makes sense.
I'd also like to test the udeb before final approval.
Cheers,
FJP
[1]http://svn.debian.org/wsvn/d-i/trunk/installer/doc/devel/menu-item-numbers.txt?op=file&rev=0&sc=0
[2]http://svn.debian.org/wsvn/d-i/trunk/packages/base-installer/kernel/i386.sh?op=file&rev=0&sc=0
Attachment:
signature.asc
Description: This is a digitally signed message part.