From: Juan Quintela <quintela@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: make qdev to use already assigned memory
Date: Fri, 11 Sep 2009 17:34:07 +0200 [thread overview]
Message-ID: <m3ocph5wcw.fsf@neno.mitica> (raw)
In-Reply-To: <4AAA6C21.8060909@redhat.com> (Gerd Hoffmann's message of "Fri, 11 Sep 2009 17:26:25 +0200")
Gerd Hoffmann <kraxel@redhat.com> wrote:
> Hi,
>
>> DeviceState *qdev_create_here(DeviceState *dev, BusState *bus, const char *name)
>>
>> The only change is that it don't want qemu_malloc(), it just initialize
>> the device in the memory that I bring there. Why do I want this?
>
> I'd prefer to not have such a function.
>
> At the end of the qdev conversion we want to have all drivers in a
> state where you can create the devices using the basic sequence ...
>
> (1) qdev_create()
> (2) setting properties
> (2) qdev_init()
>
> ... from generic code. qdev_create_here() simply doesn't fit in
> here. It can by definition not be called by generic code. Only a very
> few special cases could actually make use of it.
>
> It would make alot of sense to allow *bus* data structures being
> embedded though. A bus is never ever created on its own, it is
> allways created by the parent device (lsi creates a scsi bus, ...).
> Would that solve your problems?
At least it is a big step in the right direction :)
I think we would have to set with this one for now. If I found any
other pattern, would let you know.
> I think that one can also be solved by splitting pci bus registration
> and pci bus irq setup into two functions.
It will fix this one.
>> hw/fdc.c
>
>> struct fdctrl_t {
>> /* Command FIFO */ /* 1st field */
>> uint8_t fifo[512];
>> ....
>> };
>
>> And now I will call qemu_memalign() for the whole structure.
>
> Doesn't fly. isa-fdc is pretty close to the state where it can be
> created via -device, we just need the drive windup. When creating the
> floppy controller via '-device isa-fdc,driveA=foo,driveB=bar' or
> simliar, who will call qemu_memalign then? Also note that DeviceState
> must be at offset zero of the device state struct.
I know this one in borderline (to say the less), but I was just putting
the examples where i needed them in the last two days. I.e. that they
weren't "theoretical" problems.
Thanks, Juan.
prev parent reply other threads:[~2009-09-11 15:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-11 14:20 [Qemu-devel] make qdev to use already assigned memory Juan Quintela
2009-09-11 15:26 ` [Qemu-devel] " Gerd Hoffmann
2009-09-11 15:34 ` Juan Quintela [this message]
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=m3ocph5wcw.fsf@neno.mitica \
--to=quintela@redhat.com \
--cc=kraxel@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).