On Fri, Mar 9, 2012 at 4:50 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote:

> The mmap(2) approach doesn't support QEMU's "protocol" concept where
> an image format block driver is independent of the underlying storage
> (host file system, NBD, HTTP, etc).  In QEMU block layer terminology
> NBD, HTTP, and the host file system block drivers are "protocols" in
> that they give access to data.  It's not possible to mmap(2) over NBD
> or HTTP.
>
> (I'm doing a linear code review, so perhaps your later patches avoid
> using mmap.  But at this point I wanted to comment on this.)
>
indeed mmap() is used in the code.  This is unfortunate that it cannot be
used.  It's a really high performance way to achieve what we want here, and
very safe for the use-case.  Of course the only medium we support in the
product that uses this is filesystem, so I see your point.  I'll see about
using some different mechanism.

>
>
> This is a good overview.  It would be nice to see a structure-level
> specification of the file format on disk, but given this explanation
> it doesn't seem critical unless you wish to do that.
>
Thanks - I'd rather not.  The format is actually quite obvious from the
code.  It's very simple and doesn't involve any sort of clustering, etc.
 There's not much more than the overview that is not quickly understood
from the code itself (even the .h file).

This has been raised in similar situations in the past: you have BSD
> licensed this but then say "All Rights Reserved".  What does that
> mean?  You have just given rights to distribute, modify, etc through
> the BSD license so I'm not sure it makes sense to reserve all rights.
> Your copyright is fine but you cannot restrict rights, that would
> conflict with QEMU's license (which overall is GPL).
>
I'm happy to hack off the "All Rights Reserved".  Our main goal is to get
this accepted upstream.  We provide value to customers with our knowledge
and our higher level frameworks, not with this disk image format by itself.
 Also as far as image formats go, as you can see, it's pretty trivial.  We
chose BSD because 1) QEMU was all BSD a few years back when we originated
this, and 2) it plays nice with both open source and closed source.  If
someone wants to take this and do what they want with it, that's fine with
me (and my company).  We have been shipping these patches for years with
our commercial product so it's not new to the market.

I have to post a v2 of the patches anyway - I'll make sure to hack off the
"All Rights Reserved" clause in those.

Thanks for your time on this,

- Leo

>
> Stefan
>

Reply via email to