|
From: | Eric Blake |
Subject: | Re: [Qemu-block] [Qemu-devel] [PATCH] block: Don't lock /dev/null and /dev/zero automatically |
Date: | Fri, 20 Jul 2018 11:35:50 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
On 07/20/2018 03: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'm not familiar with /dev/nullb* - is that a typo? $ ll /dev/nullb* ls: cannot access '/dev/nullb*': No such file or directory
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.
/dev/urandom is also a character device, and also fits in my heuristic that we likely only care about locking of block devices.
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
[Prev in Thread] | Current Thread | [Next in Thread] |