All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	qemu-block@nongnu.org
Cc: fam@euphon.net, kwolf@redhat.com, ehabkost@redhat.com,
	qemu-devel@nongnu.org, mreitz@redhat.com, stefanha@redhat.com,
	crosa@redhat.com, den@openvz.org, John Snow <jsnow@redhat.com>
Subject: Re: [PATCH v8 4/7] scripts: add block-coroutine-wrapper.py
Date: Wed, 23 Sep 2020 19:00:38 -0500	[thread overview]
Message-ID: <73781605-a817-c627-fea9-183caf84c4b6@redhat.com> (raw)
In-Reply-To: <be6408ba-a430-0294-96e8-a38af7f94c1b@virtuozzo.com>

On 9/15/20 3:02 PM, Vladimir Sementsov-Ogievskiy wrote:
> 15.09.2020 19:44, Vladimir Sementsov-Ogievskiy wrote:
>> We have a very frequent pattern of creating coroutine from function
>> with several arguments:
>>
>>    - create structure to pack parameters
>>    - create _entry function to call original function taking parameters
>>      from struct
>>    - do different magic to handle completion: set ret to NOT_DONE or
>>      EINPROGRESS or use separate bool field
>>    - fill the struct and create coroutine from _entry function and this
>>      struct as a parameter
>>    - do coroutine enter and BDRV_POLL_WHILE loop
>>
>> Let's reduce code duplication by generating coroutine wrappers.
>>
>> This patch adds scripts/block-coroutine-wrapper.py together with some
>> friends, which will generate functions with declared prototypes marked
>> by 'generated_co_wrapper' specifier.
>>

>>
>>      4. add header with generated_co_wrapper declaration into
>>         COROUTINE_HEADERS list in Makefile

This phrase is out-of-date.  I also see 4 steps here,...

>>
>> Still, no function is now marked, this work is for the following
>> commit.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy<vsementsov@virtuozzo.com>
>> ---
>>   docs/devel/block-coroutine-wrapper.rst |  54 +++++++
>>   block/block-gen.h                      |  49 +++++++
>>   include/block/block.h                  |  10 ++
>>   block/meson.build                      |   8 ++
>>   scripts/block-coroutine-wrapper.py     | 187 +++++++++++++++++++++++++
>>   5 files changed, 308 insertions(+)
>>   create mode 100644 docs/devel/block-coroutine-wrapper.rst
>>   create mode 100644 block/block-gen.h
>>   create mode 100755 scripts/block-coroutine-wrapper.py
> 
> 
> Also needed:
> 
> diff --git a/docs/devel/index.rst b/docs/devel/index.rst
> index 04773ce076..cb0abe1e69 100644
> --- a/docs/devel/index.rst
> +++ b/docs/devel/index.rst
> @@ -31,3 +31,4 @@ Contents:
>      reset
>      s390-dasd-ipl
>      clocks
> +   block-coroutine-wrapper

I've squashed that in.

> +++ b/docs/devel/block-coroutine-wrapper.rst
> @@ -0,0 +1,54 @@
> +=======================
> +block-coroutine-wrapper
> +=======================
> +
> +A lot of functions in QEMJ block layer (see ``block/*``) can by called

QEMU

s/by called only/only be called/

> +only in coroutine context. Such functions are normally marked by

by the

> +coroutine_fn specifier. Still, sometimes we need to call them from
> +non-coroutine context, for this we need to start a coroutine, run the


s/context,/context;/

> +needed function from it and wait for coroutine finish in

in a

> +BDRV_POLL_WHILE() loop. To run a coroutine we need a function with one
> +void* argument. So for each coroutine_fn function, which needs

needs a

> +non-coroutine interface, we should define a structure to pack the
> +parameters, define a separate function to unpack the parameters and
> +call the original function and finally define a new interface function
> +with same list of arguments as original one, which will pack the
> +parameters into a struct, create a coroutine, run it and wait in
> +BDRV_POLL_WHILE() loop. It's boring to create such wrappers by hand, so
> +we have a script to generate them.
> 
> +Usage
> +=====
> +
> +Assume we have defined ``coroutine_fn`` function
> +``bdrv_co_foo(<some args>)`` and need a non-coroutine interface for it,
> +called ``bdrv_foo(<same args>)``. In this case the script can help. To
> +trigger the generation:
> +
> +1. You need ``bdrv_foo`` declaration somewhere (for example in
> +   ``block/coroutines.h`` with ``generated_co_wrapper`` mark,
> +   like this:

Missing a closing ).

> +
> +.. code-block:: c
> +
> +    int generated_co_wrapper bdrv_foor(<some args>);

s/foor/foo/

> +
> +2. You need to feed this declaration to block-coroutine-wrapper script.

to the block-

> +   For this, add .h (or .c) file with the declaration to
> +   ``input: files(...)`` list of ``block_gen_c`` target declaration in
> +   ``block/meson.build``
> +
> +You are done. On build, coroutine wrappers will be generated in

s/On/During the/

> +``<BUILD_DIR>/block/block-gen.c``.

...but 2 in the .rst.  Presumably, the .rst steps belong in the commit 
message as well.

> +++ b/block/block-gen.h

> +++ b/include/block/block.h
> @@ -10,6 +10,16 @@
>  #include "block/blockjob.h"
>  #include "qemu/hbitmap.h"
>  
> +/*
> + * generated_co_wrapper
> + *
> + * Function specifier, which does nothing but marking functions to be

s/marking/mark/

> + * generated by scripts/block-coroutine-wrapper.py
> + *
> + * Read more in docs/devel/block-coroutine-wrapper.rst
> + */
> +#define generated_co_wrapper
> +
>  /* block.c */
>  typedef struct BlockDriver BlockDriver;
>  typedef struct BdrvChild BdrvChild;
> diff --git a/block/meson.build b/block/meson.build
> index a3e56b7cd1..88ad73583a 100644
> --- a/block/meson.build
> +++ b/block/meson.build
> @@ -107,6 +107,14 @@ module_block_h = custom_target('module_block.h',
>                                 command: [module_block_py, '@OUTPUT0@', modsrc])
>  block_ss.add(module_block_h)
>  
> +wrapper_py = find_program('../scripts/block-coroutine-wrapper.py')
> +block_gen_c = custom_target('block-gen.c',
> +                            output: 'block-gen.c',
> +                            input: files('../include/block/block.h',
> +                                         'coroutines.h'),
> +                            command: [wrapper_py, '@OUTPUT@', '@INPUT@'])
> +block_ss.add(block_gen_c)
> +
>  block_ss.add(files('stream.c'))

I tested that this works (I'm not a meson expert, but if it works, your 
patch can't be too far off ;)

>  
>  softmmu_ss.add(files('qapi-sysemu.c'))
> diff --git a/scripts/block-coroutine-wrapper.py b/scripts/block-coroutine-wrapper.py
> new file mode 100755
> index 0000000000..d859c07a5f
> --- /dev/null
> +++ b/scripts/block-coroutine-wrapper.py
> @@ -0,0 +1,187 @@
> +#!/usr/bin/env python3
> +"""Generate coroutine wrappers for block subsystem.
> +
> +The program parses one or several concatenated c files from stdin,
> +searches for functions with 'generated_co_wrapper' specifier

with the

> +and generates corresponding wrappers on stdout.
> +
> +Usage: block-coroutine-wrapper.py generated-file.c FILE.[ch]...
> +
> +Copyright (c) 2020 Virtuozzo International GmbH.
> +
> +This program is free software; you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation; either version 2 of the License, or
> +(at your option) any later version.
> +
> +This program is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +GNU General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with this program.  If not, see <http://www.gnu.org/licenses/>.
> +"""

John had a patch that unified how copyrights are (or are not) placed in 
doc comments.  I'm of the opinion that it may be easier to apply this 
patch as written and let him touch it up later, rather than forcing it 
to delay longer waiting for his style patches to land first, but I'm 
open to discussion on alternate approaches.

> +
> +import sys
> +import re
> +import subprocess
> +import json
> +from typing import Iterator
> +
> +
> +def prettify(code: str) -> str:
> +    """Prettify code using clang-format if available"""

Nothing else in the codebase uses clang-format, yet.  Is this an 
optional dependency we should be documenting somewhere?

> +
> +    try:
> +        style = json.dumps({
> +            'IndentWidth': 4,
> +            'BraceWrapping': {'AfterFunction': True},
> +            'BreakBeforeBraces': 'Custom',
> +            'SortIncludes': False,
> +            'MaxEmptyLinesToKeep': 2
> +        })

Is it worth always using a trailing comma, so that future additions 
don't have as many lines to touch?

> +        p = subprocess.run(['clang-format', f'-style={style}'], check=True,
> +                           encoding='utf-8', input=code,
> +                           stdout=subprocess.PIPE)
> +        return p.stdout
> +    except FileNotFoundError:
> +        return code
> +
> +
> +def gen_header():
> +    copyright = re.sub('^.*Copyright', 'Copyright', __doc__, flags=re.DOTALL)
> +    copyright = re.sub('^(?=.)', ' * ', copyright.strip(), flags=re.MULTILINE)
> +    copyright = re.sub('^$', ' *', copyright, flags=re.MULTILINE)
> +    return f"""\
> +/*
> + * File is generated by scripts/block-coroutine-wrapper.py
> + *
> +{copyright}
> + */
> +
> +#include "qemu/osdep.h"
> +#include "block/coroutines.h"
> +#include "block/block-gen.h"
> +#include "block/block_int.h"\
> +"""
> +
> +
> +class ParamDecl:
> +    param_re = re.compile(r'(?P<decl>'
> +                          r'(?P<type>.*[ *])'
> +                          r'(?P<name>[a-z][a-z0-9_]*)'
> +                          r')')
> +
> +    def __init__(self, param_decl: str) -> None:
> +        m = self.param_re.match(param_decl.strip())
> +        if m is None:
> +            raise ValueError(f'Wrong parameter declaration: "{param_decl}"')
> +        self.decl = m.group('decl')
> +        self.type = m.group('type')
> +        self.name = m.group('name')
> +
> +
> +class FuncDecl:
> +    def __init__(self, return_type: str, name: str, args: str) -> None:
> +        self.return_type = return_type.strip()
> +        self.name = name.strip()
> +        self.args = [ParamDecl(arg.strip()) for arg in args.split(',')]
> +
> +    def gen_list(self, format: str) -> str:
> +        return ', '.join(format.format_map(arg.__dict__) for arg in self.args)
> +
> +    def gen_block(self, format: str) -> str:
> +        return '\n'.join(format.format_map(arg.__dict__) for arg in self.args)
> +
> +
> +# Match wrappers declared with a generated_co_wrapper mark
> +func_decl_re = re.compile(r'^int\s*generated_co_wrapper\s*'
> +                          r'(?P<wrapper_name>[a-z][a-z0-9_]*)'
> +                          r'\((?P<args>[^)]*)\);$', re.MULTILINE)
> +
> +
> +def func_decl_iter(text: str) -> Iterator:
> +    for m in func_decl_re.finditer(text):
> +        yield FuncDecl(return_type='int',
> +                       name=m.group('wrapper_name'),
> +                       args=m.group('args'))
> +
> +
> +def snake_to_camel(func_name: str) -> str:
> +    """
> +    Convert underscore names like 'some_function_name' to camel-case like
> +    'SomeFunctionName'
> +    """
> +    words = func_name.split('_')
> +    words = [w[0].upper() + w[1:] for w in words]
> +    return ''.join(words)
> +
> +
> +def gen_wrapper(func: FuncDecl) -> str:
> +    assert func.name.startswith('bdrv_')
> +    assert not func.name.startswith('bdrv_co_')
> +    assert func.return_type == 'int'
> +    assert func.args[0].type in ['BlockDriverState *', 'BdrvChild *']
> +
> +    name = 'bdrv_co_' + func.name[5:]
> +    bs = 'bs' if func.args[0].type == 'BlockDriverState *' else 'child->bs'
> +    struct_name = snake_to_camel(name)
> +
> +    return f"""\
> +/*
> + * Wrappers for {name}
> + */
> +
> +typedef struct {struct_name} {{
> +    BdrvPollCo poll_state;
> +{ func.gen_block('    {decl};') }
> +}} {struct_name};
> +
> +static void coroutine_fn {name}_entry(void *opaque)
> +{{
> +    {struct_name} *s = opaque;
> +
> +    s->poll_state.ret = {name}({ func.gen_list('s->{name}') });

Excuse my lack of python style awareness, but why are we mixing 
{nospace} and { space } on the same line?

> +    s->poll_state.in_progress = false;
> +
> +    aio_wait_kick();
> +}}
> +
> +int {func.name}({ func.gen_list('{decl}') })
> +{{
> +    if (qemu_in_coroutine()) {{
> +        return {name}({ func.gen_list('{name}') });
> +    }} else {{
> +        {struct_name} s = {{
> +            .poll_state.bs = {bs},
> +            .poll_state.in_progress = true,
> +
> +{ func.gen_block('            .{name} = {name},') }
> +        }};
> +
> +        s.poll_state.co = qemu_coroutine_create({name}_entry, &s);
> +
> +        return bdrv_poll_co(&s.poll_state);
> +    }}
> +}}"""
> +
> +
> +def gen_wrappers_file(input_code: str) -> str:
> +    res = gen_header()
> +    for func in func_decl_iter(input_code):
> +        res += '\n\n\n'
> +        res += gen_wrapper(func)
> +
> +    return prettify(res)  # prettify to wrap long lines
> +
> +
> +if __name__ == '__main__':
> +    if len(sys.argv) < 3:
> +        exit(f'Usage: {sys.argv[0]} OUT_FILE.c IN_FILE.[ch]...')
> +
> +    with open(sys.argv[1], 'w') as f_out:
> +        for fname in sys.argv[2:]:
> +            with open(fname) as f_in:
> +                f_out.write(gen_wrappers_file(f_in.read()))
> +                f_out.write('\n')

Tested-by: Eric Blake <eblake@redhat.com>

There's enough grammar fixes, and the fact that John is working on 
python cleanups, to make me wonder if we need a v9, or if I should just 
stage it where it is with any other cleanups as followups.  But I'm 
liking the reduced maintenance burden once it is in, and don't want to 
drag it out to the point that it needs more rebasing as other things 
land first.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



  reply	other threads:[~2020-09-24  0:03 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-15 16:44 [PATCH v8 0/7] coroutines: generate wrapper code Vladimir Sementsov-Ogievskiy
2020-09-15 16:44 ` [PATCH v8 1/7] block: return error-code from bdrv_invalidate_cache Vladimir Sementsov-Ogievskiy
2020-09-24  8:26   ` Philippe Mathieu-Daudé
2020-09-24 11:19   ` Stefan Hajnoczi
2020-09-15 16:44 ` [PATCH v8 2/7] block/io: refactor coroutine wrappers Vladimir Sementsov-Ogievskiy
2020-09-23 19:41   ` Eric Blake
2020-09-24  8:27   ` Philippe Mathieu-Daudé
2020-09-24 11:24   ` Stefan Hajnoczi
2020-09-15 16:44 ` [PATCH v8 3/7] block: declare some coroutine functions in block/coroutines.h Vladimir Sementsov-Ogievskiy
2020-09-23 21:47   ` Eric Blake
2020-09-24  8:34   ` Philippe Mathieu-Daudé
2020-09-24 11:25   ` Stefan Hajnoczi
2020-09-15 16:44 ` [PATCH v8 4/7] scripts: add block-coroutine-wrapper.py Vladimir Sementsov-Ogievskiy
2020-09-15 20:02   ` Vladimir Sementsov-Ogievskiy
2020-09-24  0:00     ` Eric Blake [this message]
2020-09-24  1:20       ` Eric Blake
2020-09-24  7:08         ` Vladimir Sementsov-Ogievskiy
2020-09-24  6:59       ` Vladimir Sementsov-Ogievskiy
2020-09-24 16:20       ` John Snow
2020-09-24  0:18   ` Eric Blake
2020-09-24  7:08     ` Vladimir Sementsov-Ogievskiy
2020-09-24 11:40   ` Stefan Hajnoczi
2020-09-24 17:56   ` Eric Blake
2020-09-24 18:52     ` Vladimir Sementsov-Ogievskiy
2020-09-15 16:44 ` [PATCH v8 5/7] block: generate coroutine-wrapper code Vladimir Sementsov-Ogievskiy
2020-09-24 12:14   ` Stefan Hajnoczi
2020-09-15 16:44 ` [PATCH v8 6/7] block: drop bdrv_prwv Vladimir Sementsov-Ogievskiy
2020-09-24  8:31   ` Philippe Mathieu-Daudé
2020-09-24 12:15   ` Stefan Hajnoczi
2020-09-15 16:44 ` [PATCH v8 7/7] block/io: refactor save/load vmstate Vladimir Sementsov-Ogievskiy
2020-09-23 20:10   ` Eric Blake
2020-09-24  7:20     ` Vladimir Sementsov-Ogievskiy
2020-09-24 12:16   ` Stefan Hajnoczi
2020-09-24 12:16 ` [PATCH v8 0/7] coroutines: generate wrapper code Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=73781605-a817-c627-fea9-183caf84c4b6@redhat.com \
    --to=eblake@redhat.com \
    --cc=crosa@redhat.com \
    --cc=den@openvz.org \
    --cc=ehabkost@redhat.com \
    --cc=fam@euphon.net \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vsementsov@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.