From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=49289 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Oz7gT-0005dK-Gn
	for qemu-devel@nongnu.org; Fri, 24 Sep 2010 08:47:26 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <armbru@redhat.com>) id 1Oz7gS-00089H-5R
	for qemu-devel@nongnu.org; Fri, 24 Sep 2010 08:47:25 -0400
Received: from mx1.redhat.com ([209.132.183.28]:29281)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <armbru@redhat.com>) id 1Oz7gR-000897-TR
	for qemu-devel@nongnu.org; Fri, 24 Sep 2010 08:47:24 -0400
From: Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] CMOS file support
References: <1284645517-32743-1-git-send-email-mathias.krause@secunet.com>
	<4C9251C6.2090705@codemonkey.ws> <4C930F9B.5010007@secunet.com>
	<4C936CDC.1030207@codemonkey.ws> <4C9A5C61.7030508@secunet.com>
Date: Fri, 24 Sep 2010 14:47:19 +0200
In-Reply-To: <4C9A5C61.7030508@secunet.com> (Mathias Krause's message of "Wed,
	22 Sep 2010 21:43:29 +0200")
Message-ID: <m3lj6rz4tk.fsf@blackfin.pond.sub.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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.nongnu.org/archive/html/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: Mathias Krause <mathias.krause@secunet.com>
Cc: qemu-devel@nongnu.org

Mathias Krause <mathias.krause@secunet.com> writes:

> On 17.09.2010 15:27, Anthony Liguori wrote:
>> On 09/17/2010 01:50 AM, Mathias Krause wrote:
>>> Am 16.09.2010 19:20 schrieb Anthony Liguori:
>>>   
>>>> Instead of using FILE, I'd suggest using a BlockDriver to read and write
>>>> the data.
>>>>      
>>> I'll fix that as soon as I figured how to use this interface.
>>>
>>>   
>>>> I think it would be very nice to add write support too so that writes to
>>>> CMOS were persisted across boots.
>>>>      
>>> Indeed. Also I would like to have a command line interface like '-cmos
>>> cmos.bin' instead of the ugly '-global mc146818rtc.file=cmos.bin'. But
>>> I'm not aware how to create such an alias. Any pointers?
>>>    
>> 
>> Unfortunately, it's a little complicated although it should get better
>> in the future.   The right way to do this today would be:
>> 
>>   -drive file=cmos.bin,if=none,id=nvram -global mc146818rtc.drive=nvram
>> 
>> The use of -drive is historic.  We'll have a better option in the future
>> that will look something like:
>> 
>>  -blockdev file=cmos.bin,id=nvram -global mc146818rtc.drive=nvram
>
> Well, I guess "better" lies in the eye of the beholder, then ;)
>
>
>> But in either case, I'd suggest adding an -nvram option that was:
>> 
>>  -nvram <filename>
>> 
>> Which would do:
>> 
>>   drive_add(optarg, "if=none,id=nvram");
>> 
>> And then in the RTC code, default drive to nvram.
>
> I managed to add the nvram option but how do I get a reference to the
> drive back in the RTC code? Would I just loop with drive_get(IF_NONE, 0,
> i) until the id of the returned drive is "nvram"? Doesn't sound right
> but I've found no better solution due to the lack of an
> drive_get_by_id() function.

Use DEFINE_PROP_DRIVE() to define mc146818rtc's property drive, and it's
automatic: qdev assigns a pointer to the BlockDriverState.

To access DriveInfo, use drive_get_by_blockdev().  I doubt you need
that.

[...]