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@xxxxxxxxx> 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@xxxxxxxxx> > > 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@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
