Re: development/hacking environment reg.

[Anand Arumugam <anand.arumug@xxxxxxxxx>]

Thanks a bunch for your detailed reply. It really gave me some idea. Even if its not something related to the nuts and bolts of the target hardware, how does one go about test the fix in other architectures say SPARC/MIPS/ARM/SH*??? Can that be achieved using QEMU or can this be done using VirtualBox itself?

Cheers,
-Anand.

On Wed, Sep 30, 2009 at 1:15 AM, Michal Ludvig <mludvig@xxxxxxxxxxxx> wrote:

Anand Arumugam wrote:

> what is the
> normal environment that is used by most of the kernel hackers and
> developers? do they have a dedicated pc for this work and have a
> separate pc for other uses? or just create a partition in the hard drive
> and use this partition for kernel related development?

I guess it really depends on what sort of kernel development you do. If
it's something that doesn't need access to the hardware, for instance a
new filesystem, you can get away with a virtual machine in VirtualBox or
KVM or Xen. On the other hand if you need access to the metal, when
writing device drivers for example, you're better off having a dedicated
machine since you are likely to experience frequent reboots.

To give an example - I work, edit code, browse documentation, etc on my
workstation. That one hardly ever gets rebooted. The code I write for a
given project is in a NFS-exported dir and that dir is mounted on a one
of my test systems where I compile and test it. If it works - good, if
it breaks - never mind. All I need is to reboot or powercycle the test
machine and in the mean time, on my workstation, fix the problem and get
ready for another test. That means that my work environment (open files
in editor, open documentation PDFs, etc) is not disturbed if the test
system crashes. And it also means that all my code is in one place, not
scattered among many different systems.

I don't need a keyboard and screen for each system - all of them are
networked and most of the time I ssh to them from the comfort of my
workstation (using a dedicated password-less ssh key to make it even
simpler). Actually some of my embedded boards only have a serial console
and no network, but that's a whole different story.

My test systems are often low-spec machines that you can buy 2nd hand
for a few bucks from ebay or similar sites. Not a big investment for the
comfort you gain from having a dedicated test system.

I'm sure other developers prefer different setups. This is merely a way
that works for me.

HTH,

Michal