On Fri, Mar 9, 2012 at 4:50 AM, Stefan Hajnoczi
<address@hidden> wrote:
The mmap(2) approach doesn't support QEMU's "protocol" concept where
(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