All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Mathias Krause <mathias.krause@secunet.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] CMOS file support
Date: Fri, 24 Sep 2010 14:40:21 +0200	[thread overview]
Message-ID: <m3tylfz556.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <4C9350E9.6000300@secunet.com> (Mathias Krause's message of "Fri, 17 Sep 2010 13:28:41 +0200")

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

> Hi Kevin,
>
> On 17.09.2010 12:44, Kevin Wolf wrote:
>> Hi Mathias,
>> 
>> Am 17.09.2010 08:42, schrieb Mathias Krause:
>>>> Using QEMU's block devices instead of a simple file would be
>>>> more consistent with the rest of QEMU and allow reading the
>>>> CMOS data not only from a file but also from an URL or other
>>>> sources.
>>> Thanks for the hint. Since this is my first contribution to the project
>>> I'm not that familiar with the code. Looking at other places, e.g. how
>>> the -kernel option gets handled, I just see FILE everywhere. Can you
>>> give me some pointers how to use this interface?
>> 
>> Have a look at block.h which contains the prototypes for the public
>> block layer interface.
>> 
>> Basically, you need to create a BlockDriverState with bdrv_new() and
>> then open it with bdrv_open(). You'll want to specify the raw block
>> driver for opening the image, you get it with bdrv_find_format("raw").
>> bdrv_pread/pwrite are the right functions to access the file with byte
>> granularity (other functions work on 512 byte sectors). bdrv_delete
>> frees the the BlockDriverState when you're done.
>
> Thank you for the detailed writeup. I think I should figure out how to
> use it myself now. Albeit there seem to be not many users of this
> interface right now. Looks like it's currently only used for storage
> devices. So I'm questioning myself: What _real_ benefit would it bring
> to use the QEMU block device layer for the CMOS file?

I'd view initial CMOS contents as configuration.  We don't use the block
layer to access configuration files.

  reply	other threads:[~2010-09-24 12:40 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-16 13:58 [Qemu-devel] [PATCH] CMOS file support Mathias Krause
2010-09-16 16:49 ` Stefan Weil
2010-09-17  6:42   ` Mathias Krause
2010-09-17 10:44     ` Kevin Wolf
2010-09-17 11:28       ` Mathias Krause
2010-09-24 12:40         ` Markus Armbruster [this message]
2010-09-17 10:58     ` Stefan Weil
2010-09-17 11:16       ` Mathias Krause
2010-09-16 17:20 ` Anthony Liguori
2010-09-17  6:50   ` Mathias Krause
2010-09-17 13:27     ` Anthony Liguori
2010-09-22 19:43       ` Mathias Krause
2010-09-23 12:12         ` [Qemu-devel] " Paolo Bonzini
2010-09-24 12:47         ` [Qemu-devel] " Markus Armbruster
2010-09-26 20:44           ` Mathias Krause
2010-10-11 13:25             ` Markus Armbruster
2010-09-24 12:42   ` Markus Armbruster

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=m3tylfz556.fsf@blackfin.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mathias.krause@secunet.com \
    --cc=qemu-devel@nongnu.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.