From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1HJK57-0007B3-Az
	for qemu-devel@nongnu.org; Mon, 19 Feb 2007 20:46:13 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1HJK54-0007Ar-VZ
	for qemu-devel@nongnu.org; Mon, 19 Feb 2007 20:46:12 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1HJK54-0007Ao-Pe
	for qemu-devel@nongnu.org; Mon, 19 Feb 2007 20:46:10 -0500
Received: from mail.codesourcery.com ([65.74.133.4])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1HJK54-0007DM-6E
	for qemu-devel@nongnu.org; Mon, 19 Feb 2007 20:46:10 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] FreeBSD Support
Date: Tue, 20 Feb 2007 01:46:04 +0000
References: <200702161402.23660.cwolsen@domainatlantic.com>
	<20070220010509.GC5172@redhat.com>
	<200702192015.18981.cwolsen@domainatlantic.com>
In-Reply-To: <200702192015.18981.cwolsen@domainatlantic.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200702200146.05003.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Christopher Olsen <cwolsen@domainatlantic.com>

> This is a sidetrack here... But is it at all possible to make future
> releases of the source more FreeBSD friendly?

If someone puts in the effort to make it so, yes.

Note that dumping the current patches from FreeBSD ports on the list is 
generally not sufficient. Blindly posting patches without explanation is a 
good way to get them ignored.

All patches should include a description of what they are fixing (ie. what 
qemu currently does wrong), how the patch fixes it, and why this is the right 
way to fix it. For OS specific hacks there needs to be a good reason why that 
OS is special. 
If you can't answer all the above questions then you shouldn't be submitting 
the patch. In some cases you may need to rewriting the patches to meet these 
criteria. Individual OS/Distros tend to be less picky because they only care 
whether the result works on that one system.

Paul