While we cannot represent the latency-ns option in a filename, it is not
a strong option so not being able to should not stop us from generating
a filename nonetheless.

Signed-off-by: Max Reitz <mreitz@redhat.com>
---
 block/null.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/block/null.c b/block/null.c
index c681e7e20b..24c52a15de 100644
--- a/block/null.c
+++ b/block/null.c
@@ -252,7 +252,8 @@ static void null_refresh_filename(BlockDriverState *bs)
     {
         /* These options can be ignored */
         if (strcmp(qdict_entry_key(e), "filename") &&
-            strcmp(qdict_entry_key(e), "driver"))
+            strcmp(qdict_entry_key(e), "driver") &&
+            strcmp(qdict_entry_key(e), NULL_OPT_LATENCY))
         {
             return;
         }
-- 
2.17.1

On Thu 09 Aug 2018 11:35:26 PM CEST, Max Reitz wrote:
> While we cannot represent the latency-ns option in a filename, it is not
> a strong option so not being able to should not stop us from generating
> a filename nonetheless.
>
> Signed-off-by: Max Reitz <mreitz@redhat.com>

I thought I had reviewed this one already ?

Reviewed-by: Alberto Garcia <berto@igalia.com>

Berto

On 2018-08-28 15:33, Alberto Garcia wrote:
> On Thu 09 Aug 2018 11:35:26 PM CEST, Max Reitz wrote:
>> While we cannot represent the latency-ns option in a filename, it is not
>> a strong option so not being able to should not stop us from generating
>> a filename nonetheless.
>>
>> Signed-off-by: Max Reitz <mreitz@redhat.com>
> 
> I thought I had reviewed this one already ?

Hm, maybe I forgot to add your R-b tag?  Or maybe there was some
non-trivial rebase change...  I don't know.

Max