From: Sasha Levin <levinsasha928@gmail.com>
To: Pekka Enberg <penberg@kernel.org>
Cc: kvm@vger.kernel.org, mingo@elte.hu, asias.hejun@gmail.com,
gorcunov@gmail.com
Subject: Re: [PATCH 02/11] kvm tools: Hold a copy of ops struct inside disk_image
Date: Tue, 01 Nov 2011 13:43:31 +0200 [thread overview]
Message-ID: <1320147811.3847.15.camel@lappy> (raw)
In-Reply-To: <CAOJsxLFq0ZpwiX9S_KdNYqbBU3oHz+Y3kjmgGxjJd7=fg0Kxxw@mail.gmail.com>
On Tue, 2011-11-01 at 13:30 +0200, Pekka Enberg wrote:
> Hi Sasha,
>
> On Sun, Oct 30, 2011 at 7:35 PM, Sasha Levin <levinsasha928@gmail.com> wrote:
> >> > This makes passing different ops structures easier since you don't have
> >> > to keep them somewhere else after initializing disk_image.
> >> >
> >> > Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
>
> On Tue, 2011-11-01 at 08:44 +0200, Pekka Enberg wrote:
> >> Why do we want to do this? Why would you ever want to allocate ops via
> >> malloc() or on the stack?
>
> On Tue, Nov 1, 2011 at 1:16 PM, Sasha Levin <levinsasha928@gmail.com> wrote:
> > It's mostly there to avoid having to either keep ops in a global struct
> > or to malloc() them, instead - it just holds them as part of disk_image;
> >
> > It's useful with how we handle read-only ops now, you can see how we use
> > RO image now (private mmap() with fallback to AIO with no write op).
>
> It's not useful, it's obfuscation. The whole point of "operations"
> struct is to provide an immutable and stateless virtual function
> dispatch table. It's absolutely pointless to use malloc() to hold them
> and seems to miss the whole point of keeping data and function pointer
> separate.
It does provide a stateless function dispatch table, the only difference
is how the function ptr is stored in disk_image.
How would you implement the fallback thing we have in RO images now?
declare all those ops as global variables?
--
Sasha.
next prev parent reply other threads:[~2011-11-01 11:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-30 17:35 [PATCH 00/11] kvm tools: Support native vectored AIO Sasha Levin
2011-10-30 17:35 ` [PATCH 01/11] kvm tools: Switch to using an enum for disk image types Sasha Levin
2011-10-30 17:35 ` [PATCH 02/11] kvm tools: Hold a copy of ops struct inside disk_image Sasha Levin
2011-11-01 6:44 ` Pekka Enberg
2011-11-01 11:16 ` Sasha Levin
2011-11-01 11:30 ` Pekka Enberg
2011-11-01 11:43 ` Sasha Levin [this message]
2011-11-01 11:52 ` Pekka Enberg
2011-10-30 17:35 ` [PATCH 03/11] kvm tools: Remove the non-iov interface from disk image ops Sasha Levin
2011-10-30 17:35 ` [PATCH 04/11] kvm tools: Modify disk ops usage Sasha Levin
2011-10-30 17:35 ` [PATCH 05/11] kvm tools: Modify behaviour on missing ops ptr Sasha Levin
2011-10-30 17:35 ` [PATCH 06/11] kvm tools: Add optional callback on disk op completion Sasha Levin
2011-10-30 17:35 ` [PATCH 07/11] kvm tools: Remove qcow nowrite function Sasha Levin
2011-10-30 17:35 ` [PATCH 08/11] kvm tools: Split io request from completion Sasha Levin
2011-10-31 10:42 ` Asias He
2011-10-30 17:35 ` [PATCH 09/11] kvm tools: Hook virtio-blk completion to disk op completion Sasha Levin
2011-10-30 17:35 ` [PATCH 10/11] kvm tools: Add aio read write functions Sasha Levin
2011-10-30 17:35 ` [PATCH 11/11] kvm tools: Use native vectored AIO in virtio-blk Sasha Levin
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=1320147811.3847.15.camel@lappy \
--to=levinsasha928@gmail.com \
--cc=asias.hejun@gmail.com \
--cc=gorcunov@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=penberg@kernel.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.