From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LnU5u-00014E-Jl
	for qemu-devel@nongnu.org; Sat, 28 Mar 2009 04:40:46 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LnU5q-00013V-Up
	for qemu-devel@nongnu.org; Sat, 28 Mar 2009 04:40:46 -0400
Received: from [199.232.76.173] (port=57884 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LnU5q-00013S-Pd
	for qemu-devel@nongnu.org; Sat, 28 Mar 2009 04:40:42 -0400
Received: from mail-fx0-f169.google.com ([209.85.220.169]:32960)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <blauwirbel@gmail.com>) id 1LnU5q-0000Uu-Ez
	for qemu-devel@nongnu.org; Sat, 28 Mar 2009 04:40:42 -0400
Received: by fxm17 with SMTP id 17so1195913fxm.34
	for <qemu-devel@nongnu.org>; Sat, 28 Mar 2009 01:40:41 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <20090323224602.GA40711@saturn.kn-bremen.de>
References: <20090323224602.GA40711@saturn.kn-bremen.de>
Date: Sat, 28 Mar 2009 10:40:41 +0200
Message-ID: <f43fc5580903280140ie068b79sd0aef2c11bfcaff8@mail.gmail.com>
Subject: Re: [Qemu-devel] [PATCH:] FreeBSD host physical cdrom fixes
From: Blue Swirl <blauwirbel@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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

On 3/24/09, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> This improves physical cdrom support on FreeBSD hosts to be almost as
>  good as on Linux, with the only notable exception that you still need to
>  either have the guest itself eject the disc if you want to take it
>  out/change it, or do a change command in the monitor after taking out
>  a disc in case a guest cannot eject it itself - otherwise the guest may
>  continue using state (like size) of the old disc.
>
>   [Yes this is not perfect but still is way better than the old state of
>  things and thus commit-worthy in my opinion.  I don't think it needs
>  to be committed in incremental pieces, if you disagree please say so.]

Thanks, applied. OpenBSD also has cdio and the header shows NetBSD
ancestry, so maybe this works for all HOST_BSD? My OpenBSD machine
does not have a cdrom, so I can't test it.