All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: adam.keys@HOTARD.engr.smu.edu
Cc: linux-kernel@vger.kernel.org
Subject: Re: Development Setups
Date: Fri, 05 Oct 2001 09:02:03 +0100	[thread overview]
Message-ID: <19213.1002268923@redhat.com> (raw)
In-Reply-To: <20011005041759.OPDP14306.femail26.sdc1.sfba.home.com@there>
In-Reply-To: <20011005041759.OPDP14306.femail26.sdc1.sfba.home.com@there>


adam.keys@engr.smu.edu said:
> I was thinking of starting with a modern machine for developing/
> compiling on,  and then older machine(s) for testing.  This way I
> would not risk losing data  if I oops or somesuch. 

With journalling filesystems you needn't worry _too_ much about losing 
data; depending of course on what you're hacking on. Having two separate 
boxen for development and testing is mostly valuable because you can keep 
working when you break it - it doesn't take your entire desktop environment 
down with it.


adam.keys@engr.smu.edu said:
>  Which brings me to the final question.  Is there any reason to choose
>  architecture A over architecture B for any reason besides
> arch-specific  development in the kernel or for device drivers?

If you're developing device drivers and have the choice, pick something 
esoteric to enforce good behaviour. Something which does out-of-order 
stores, has non-cache-coherent DMA, is big-endian and preferably 64-bit. I 
think both mips64 and sparc64 boards can meet all those criteria - if not, 
get as close as you can. 

--
dwmw2



  parent reply	other threads:[~2001-10-05  8:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-05  4:20 Development Setups Adam Keys
2001-10-05  4:36 ` Michael Rothwell
2001-10-05  8:02 ` David Woodhouse [this message]
2001-10-06  0:27   ` journaling and devel [was Re: Development Setups] Pavel Machek
2001-10-13 20:30     ` Steve Lord
2001-10-05  9:50 ` Development Setups Riley Williams
2001-10-05 11:22 ` Alan Cox
2001-10-05 14:53 ` Jeff Dike
2001-10-05 17:15 ` Andrew Ebling
2001-10-06 11:38   ` Adrian Cox
2001-10-13 20:38 ` Tim Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19213.1002268923@redhat.com \
    --to=dwmw2@infradead.org \
    --cc=adam.keys@HOTARD.engr.smu.edu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.