On 2018-08-20 04:07, Fam Zheng wrote:
> On Thu, 08/16 04:20, Max Reitz wrote:
>> No, the real issue is that dd is still not implemented just as a
>> frontend to convert. Which it should be. I'm not sure dd was a very
>> good idea from the start, and now it should ideally be a frontend to
>> conve
On Thu, 08/16 04:20, Max Reitz wrote:
> No, the real issue is that dd is still not implemented just as a
> frontend to convert. Which it should be. I'm not sure dd was a very
> good idea from the start, and now it should ideally be a frontend to
> convert.
>
> (My full opinion on the matter: dd
On 2018-08-16 09:15, Kevin Wolf wrote:
> Am 16.08.2018 um 04:49 hat Max Reitz geschrieben:
>> On 2018-08-16 04:39, Eric Blake wrote:
>>> If convert were more powerful, I'd be fine dropping 'qemu-img dd' after
>>> a proper deprecation period.
>>
>> Technically it has those features already, with the
Am 16.08.2018 um 04:49 hat Max Reitz geschrieben:
> On 2018-08-16 04:39, Eric Blake wrote:
> > If convert were more powerful, I'd be fine dropping 'qemu-img dd' after
> > a proper deprecation period.
>
> Technically it has those features already, with the raw block driver's
> offset and size param
On 2018-08-16 04:57, Eric Blake wrote:
> On 08/15/2018 09:49 PM, Max Reitz wrote:
>
In my opinion, we do not want feature parity with dd. What we do want
is feature parity with convert.
>>>
>>> Well, convert is lacking a way to specify a subset of one file to move
>>> to a (possibly dif
On 08/15/2018 09:49 PM, Max Reitz wrote:
In my opinion, we do not want feature parity with dd. What we do want
is feature parity with convert.
Well, convert is lacking a way to specify a subset of one file to move
to a (possibly different) subset of the other. I'm fine if we want to
enhance
On 2018-08-16 04:39, Eric Blake wrote:
> On 08/15/2018 09:20 PM, Max Reitz wrote:
>> On 2018-08-15 04:56, Eric Blake wrote:
>>> For feature parity with dd, we want to be able to specify
>>> the offset within the output file, just as we can specify
>>> the offset for the input (in particular, this m
On 08/15/2018 09:39 PM, Eric Blake wrote:
(My full opinion on the matter: dd has a horrible interface. I don't
quite see why we replicated that inside qemu-img. Also, if you want to
use dd, why not use qemu-nbd + Linux nbd device + real dd?)
Because of performance: qemu-nbd + Linux nbd devic
On 08/15/2018 09:20 PM, Max Reitz wrote:
On 2018-08-15 04:56, Eric Blake wrote:
For feature parity with dd, we want to be able to specify
the offset within the output file, just as we can specify
the offset for the input (in particular, this makes copying
a subset range of guest-visible bytes fr
On 2018-08-15 04:56, Eric Blake wrote:
> For feature parity with dd, we want to be able to specify
> the offset within the output file, just as we can specify
> the offset for the input (in particular, this makes copying
> a subset range of guest-visible bytes from one file to
> another much easier
For feature parity with dd, we want to be able to specify
the offset within the output file, just as we can specify
the offset for the input (in particular, this makes copying
a subset range of guest-visible bytes from one file to
another much easier).
The code style for 'qemu-img dd' was pretty h
11 matches
Mail list logo
