On 02/22/2012 10:54 AM, Andreas Färber wrote:
> Am 22.02.2012 02:11, schrieb David Gibson:
>> On Tue, Feb 21, 2012 at 10:09:01AM +0100, Kevin Wolf wrote:
>>> Am 21.02.2012 09:35, schrieb Paolo Bonzini:
>>>> On 02/20/2012 11:50 AM, Alexander Graf wrote:
>>>>>>> DMAAIOCB *dbs = qemu_aio_get(&dma_aio_pool, bs, cb, opaque);
>>>>>>>
>>>>>>> - trace_dma_bdrv_io(dbs, bs, sector_num, to_dev);
>>>>>>> + trace_dma_bdrv_io(dbs, bs, sector_num, dir);
>>>>> Was the trace wrong before or is it now? I don't see its definition
>>>>> changed anywhere.
>>>>
>>>> Not sure what you mean. :)
>>>
>>> trace-events:
>>>
>>> dma_bdrv_io(void *dbs, void *bs, int64_t sector_num, bool to_dev)
>>> "dbs=%p bs=%p sector_num=%" PRId64 " to_dev=%d"
>>
>> Ah, damnit. Didn't find that file. I'll resubmit with trace-events
>> updated too.
>>
>>> to_dev is declared bool here, and it should also be renamed to dir (the
>>> unfortunate thing about DMADirection is that it swaps 0 and 1 compared
>>> to bool to_dev... We need to check carefully that all occurrences have
>>> been caught.)
>>
>> Yeah. And even more unfortunate that afaict there's no way to make
>> gcc warn on enum<->bool conversions. Still there are only about 4
>> callers of dma_bdrv_io() - nearly everything uses the
>> dma_bdrv_{read,write}() wrappers - so I'm confident I got them all.
>
> Re all occurrences: megasas might be affected by such a change, too
> (patch on the list).
>
Nope. megasas is using the scsi interface for reading/writing,
so it should be insulated against this kind of change.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
