On Mon, Jul 27, 2020 at 09:26:32AM -0400, Nick Rosbrook wrote: > Add a Function and CtxFunction classes to idl.py to allow generator > scripts to generate wrappers which are repetitive and straight forward > when doing so by hand. Examples of such functions are the > device_add/remove functions. > > To start, a Function has attributes for namespace, name, parameters, > return type, and an indication if the return value should be interpreted as > a status code. The CtxFunction class extends this by indicating that a > libxl_ctx is a required parmeter, and can optionally be an async > function. > > Also, add logic to idl.parse to return the list of functions found in an > IDL file. For now, have users of idl.py -- i.e. libxl/gentypes.py and > golang/xenlight/gengotypes.py -- ignore the list of functions returned. > > Signed-off-by: Nick Rosbrook <rosbro...@ainfosec.com> > --- > > +class Function(object): > + """ > + A general description of a function signature. > + > + Attributes: > + name (str): name of the function, excluding namespace. > + params (list of (str,Type)): list of function parameters. > + return_type (Type): the Type (if any), returned by the function. > + return_is_status (bool): Indicates that the return value should be > + interpreted as an error/status code.
Can we get away without `return_is_status`? Couldn't we try to have return_type=libxl_error to indicate that return is a kind of status? > + """ > +class CtxFunction(Function): > + """ > + A function that requires a libxl_ctx. > + > + Attributes: > + is_asyncop (bool): indicates that the function accepts a > + libxl_asyncop_how parameter. While CtxFunction can be a function that takes `libxl_ctx` as first parameter, I don't think `is_asyncop` can be used. We can't know if `ao_how` will be last or not. For some function, `ao_how` is second to last. So, I guess `ao_how` might need to be listed in `params` What do you think? Thanks, -- Anthony PERARD
