On Wed, Sep 30, 2009 at 8:57 PM, Anand Arumugam <anand.arumug@xxxxxxxxx> wrote: > 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. Yes, its very much possible to emulate these archs with QEMU, I use it for arm processor related work. Or another very nice option is Marvell's SheevaPlug. It already comes with development kit with it. Explore it here, http://en.wikipedia.org/wiki/SheevaPlug -Vinit > 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 >> >> >> > > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
