qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 44/55] spitz tosa: Simplify "drive is suitable f


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 44/55] spitz tosa: Simplify "drive is suitable for microdrive" test
Date: Tue, 09 Aug 2011 14:46:59 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110707 Thunderbird/5.0

Am 09.08.2011 14:36, schrieb Markus Armbruster:
> Kevin Wolf <address@hidden> writes:
> 
>> Am 09.08.2011 13:56, schrieb Markus Armbruster:
>>> bdrv_is_locked() is about the frontend's media lock.  To make this more
>>> obvious, my PATCH 29/55 replaces it by bdrv_dev_is_medium_locked().  It
>>> does *not* query the backend's lock (which may not even exist!) set by
>>> bdrv_set_locked().
>>
>> This sounds wrong (the behaviour, not your analysis). Do you plan to
>> remove bdrv_dev_is_medium_locked() as well? It is used by IDE and
>> scsi-disk (easy to replace) and in eject_device() in blockdev.c. Maybe
>> the 'eject' monitor command should be handled by another callback into
>> the device.
> 
> Just two users remain after my series:
> 
> * bdrv_info()
> 
>   It wants to show the frontend's lock state, and uses
>   bdrv_dev_is_medium_locked() to get it from the frontend.

bdrv_info() is a nasty reason for keeping this in the block layer.

> * eject_device()
> 
>   It needs to fail if the frontend has its medium locked.  It uses
>   bdrv_dev_is_medium_locked() to get the lock state from the frontend.
>   Pseudo code (-f glossed over for simplicity):
> 
>       unless frontend has removable media
>               fail
>       if frontend medium is not already open
>          and frontend medium is locked
>               fail
>       drop the block driver
> 
>   I considered replacing this with "ask the frontend to eject", and then
>   let the frontend decide whether to order the backend to drop the block
>   driver.  I decided against it, since I need
>   bdrv_dev_is_medium_locked() anyway for bdrv_info().  Besides, the
>   series is long enough already.

I'm not asking to change it in this series, but in general I think it
would be a good change to make.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]