From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin 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 Message-ID: <1320147811.3847.15.camel@lappy> References: <1319996135-17501-1-git-send-email-levinsasha928@gmail.com> <1319996135-17501-3-git-send-email-levinsasha928@gmail.com> <1320146205.3847.13.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, mingo@elte.hu, asias.hejun@gmail.com, gorcunov@gmail.com To: Pekka Enberg Return-path: Received: from mail-gy0-f174.google.com ([209.85.160.174]:37737 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753668Ab1KALpL (ORCPT ); Tue, 1 Nov 2011 07:45:11 -0400 Received: by gyb13 with SMTP id 13so6933026gyb.19 for ; Tue, 01 Nov 2011 04:45:10 -0700 (PDT) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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 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 > > 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 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.