From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=52696 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Owaz6-0006eW-LF
	for qemu-devel@nongnu.org; Fri, 17 Sep 2010 09:28:13 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1Owaz4-0005tl-OH
	for qemu-devel@nongnu.org; Fri, 17 Sep 2010 09:28:12 -0400
Received: from mail-iw0-f173.google.com ([209.85.214.173]:34261)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1Owaz4-0005te-LS
	for qemu-devel@nongnu.org; Fri, 17 Sep 2010 09:28:10 -0400
Received: by iwn38 with SMTP id 38so2145716iwn.4
	for <qemu-devel@nongnu.org>; Fri, 17 Sep 2010 06:28:09 -0700 (PDT)
Message-ID: <4C936CDC.1030207@codemonkey.ws>
Date: Fri, 17 Sep 2010 08:27:56 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
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>
In-Reply-To: <4C930F9B.5010007@secunet.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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, Markus Armbruster <armbru@redhat.com>

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

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.

It gets a little tough to handle the case of in memory CMOS.

Regards,

Anthony Liguori

>    
>>> +static long get_file_size(FILE *f)
>>> +{
>>> +    long where, size;
>>> +
>>> +    /* XXX: on Unix systems, using fstat() probably makes more sense */
>>> +
>>> +    where = ftell(f);
>>> +    fseek(f, 0, SEEK_END);
>>> +    size = ftell(f);
>>> +    fseek(f, where, SEEK_SET);
>>> +
>>> +    return size;
>>> +}
>>>
>>>        
>> BlockDrivers have a getlength() functions.
>>      
> Would reduce the size of the patch which is always a good thing (tm).
>
>
> Mathias
>