Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 15 3月, 2013 1 次提交
  3. 26 1月, 2013 1 次提交
  5. 19 12月, 2012 3 次提交
  7. 24 9月, 2012 1 次提交
  9. 12 6月, 2012 2 次提交
    • M
      change qemu_iovec_to_buf() to match other to,from_buf functions · d5e6b161
      由 Michael Tokarev 提交于 
      It now allows specifying offset within qiov to start from and
amount of bytes to copy.  Actual implementation is just a call
to iov_to_buf().
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      d5e6b161
    • M
      allow qemu_iovec_from_buffer() to specify offset from which to start copying · 03396148
      由 Michael Tokarev 提交于 
      Similar to
 qemu_iovec_memset(QEMUIOVector *qiov, size_t offset,
                   int c, size_t bytes);
the new prototype is:
 qemu_iovec_from_buf(QEMUIOVector *qiov, size_t offset,
                     const void *buf, size_t bytes);

The processing starts at offset bytes within qiov.

This way, we may copy a bounce buffer directly to
a middle of qiov.

This is exactly the same function as iov_from_buf() from
iov.c, so use the existing implementation and rename it
to qemu_iovec_from_buf() to be shorter and to match the
utility function.

As with utility implementation, we now assert that the
offset is inside actual iovec.  Nothing changed for
current callers, because `offset' parameter is new.

While at it, stop using "bounce-qiov" in block/qcow2.c
and copy decrypted data directly from cluster_data
instead of recreating a temp qiov for doing that.
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      03396148
  11. 05 4月, 2012 1 次提交
  13. 26 1月, 2012 2 次提交
  15. 05 12月, 2011 2 次提交
  17. 24 11月, 2011 1 次提交
  19. 11 11月, 2011 1 次提交
  21. 29 10月, 2011 1 次提交
  23. 21 10月, 2011 2 次提交
  25. 14 10月, 2011 1 次提交
  27. 23 8月, 2011 6 次提交
  29. 21 8月, 2011 1 次提交
  31. 02 8月, 2011 1 次提交
  33. 14 6月, 2011 1 次提交
  35. 15 3月, 2011 1 次提交
  37. 25 11月, 2010 1 次提交
  39. 04 11月, 2010 1 次提交
  41. 22 6月, 2010 1 次提交
  43. 17 5月, 2010 1 次提交
  45. 03 5月, 2010 1 次提交
    • K
      block: Open the underlying image file in generic code · 66f82cee
      由 Kevin Wolf 提交于 
      Format drivers shouldn't need to bother with things like file names, but rather
just get an open BlockDriverState for the underlying protocol. This patch
introduces this behaviour for bdrv_open implementation. For protocols which
need to access the filename to open their file/device/connection/... a new
callback bdrv_file_open is introduced which doesn't get an underlying file
opened.

For now, also some of the more obscure formats use bdrv_file_open because they
open() the file themselves instead of using the block.c functions. They need to
be fixed in later patches.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      66f82cee
  47. 10 3月, 2010 1 次提交
  49. 27 1月, 2010 1 次提交
  51. 14 1月, 2010 1 次提交
  53. 11 7月, 2009 1 次提交
  55. 06 6月, 2009 1 次提交
  57. 27 5月, 2009 1 次提交