Re: [Qemu-devel] [Qemu-block] [PATCH] block: Don't lock /dev/null and /dev/zero automatically

[John Snow]

On 07/20/2018 04:24 AM, Fam Zheng wrote:
> On Thu, 07/19 13:57, John Snow wrote:
>> Should we instead modify the test in this case to not attempt to take a
>> lock on a device we know cannot meaningfully store state, or is it your
>> preference to attempt to maintain such a list in the raw driver itself?
>>
>> I guess we never want QEMU to try to lock things like /dev/zero, but I
>> don't know if there are more such pseudo-devices we should never try to
>> lock and if so, what common property unifies them such that we don't
>> have to maintain a list.
> 
> They are 0 sized anyway so I only expect them to be used in test cases like 
> the
> one we're fixing. So this really doesn't matter.  An exceptional one would be
> /dev/nullb* but that is not used in real world either.
> 

I agree in general; I'm questioning somewhat if we ought to just patch
the test instead of the driver, given that we can't really be consistent
or accurate about when we decide not to take the lock in the driver;
unless we use something like Eric's suggestion (we don't take locks on
char devices, maybe?)

> I'm not trying to maintain a complete list (e.g. /dev/urandom and /dev/nullb*
> are missing), this patch is just trying to make writing test code easier.
> 

Yeah, it's the little quality-of-life band-aid that I'm wondering if we
ought to stick in here. Granted, this fixes a test that's broken, so...

Reviewed-by: John Snow <address@hidden>

I'll let Kevin decide if we ought to patch it nicer than this.

--js

> Fam
>