From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C26C3C433E1 for ; Mon, 17 Aug 2020 15:26:26 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8FE0C238E1 for ; Mon, 17 Aug 2020 15:26:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="RUAtOcNW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8FE0C238E1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1k7h1W-0003nF-SG; Mon, 17 Aug 2020 15:26:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1k7h1V-0003n9-GD for xen-devel@lists.xenproject.org; Mon, 17 Aug 2020 15:26:09 +0000 X-Inumbo-ID: 072ebe8f-1bbf-4a75-b547-90d8285f74a8 Received: from mail-qv1-xf41.google.com (unknown [2607:f8b0:4864:20::f41]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 072ebe8f-1bbf-4a75-b547-90d8285f74a8; Mon, 17 Aug 2020 15:26:08 +0000 (UTC) Received: by mail-qv1-xf41.google.com with SMTP id cs12so7962335qvb.2 for ; Mon, 17 Aug 2020 08:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=xHM3aMczrtxEGiBnoEaBfsbBuzD5kJs1HBfhKOSpU34=; b=RUAtOcNWvYbl07SIFU75BKfAiO78oHIkX4P8tZjPRzsrhCWVZROvVDVccUckRRQ1Rn rZ69qgzKuQvwwu6+2SEJTAsGCEXMhRs+YI6B7RjIS8vPjAKgz83uuDt3hI7MPIR87d0v BLCc+MyxYZHmylHZJM4QXQMnD+kb7MBM98P9d6Ug6gyvJxOtYLTsG6osnDVB5BqevdBp gCKuckElzcLNRaQQ5RW4Mq48Agg7ZqrmPB6Mmri4zWEiGuN4HpxOlvOJhLHzsZw5qxw3 hPnBONVeHecrB8x8fLu5yrZTEkH/V17uagOAqH+hgxQDw4Ypifqtk3Cb2CqnVAwIoYYo k0iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=xHM3aMczrtxEGiBnoEaBfsbBuzD5kJs1HBfhKOSpU34=; b=VN+0+A0dI2NuzmUTIZdWtQ/KTda4nb6HtaLvjhj2FBAV2e1oObrE5RBlJ2m5JMrMRu ycw9dIJ6y6Ula4pYXy/ttfOMYJalsKqrxKskX1KCYPFtQklw2dT8AWOlJJ8EULJ+XDyu sxPrpxdS6IRvgtyoUlFGl+OSEkp1Q4bxN0DG57l5wRRqlEzRQ4aUhfNvMMknDJUNY0Ij GC+iIeaXe+755cOEG91gqD64edqlLmk/IW3/MXqOsbUOjs2AAQIXjoWrCRF08W1s+Z8X +pW1E7xLKWPaJhTWl9n4JdirKmJTjdFM4axvWtctocTrOYtv0a3B1uqvIxmTLilIo9i3 aRaw== X-Gm-Message-State: AOAM530ST2PVVn6qM1PkuOF3CvjwnsKCxephURwnwjn9+qZrF+HaNWpj T+wd94Yrv+nfqK1DownCllc= X-Google-Smtp-Source: ABdhPJw1an/NsgmTM6Pi6ls3gS8oTJmEm1/LqA/wn1vHA/87x2ocxQoig39pjY30TDSg7wFjcKS0lQ== X-Received: by 2002:ad4:560f:: with SMTP id ca15mr15225946qvb.144.1597677968122; Mon, 17 Aug 2020 08:26:08 -0700 (PDT) Received: from four (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252]) by smtp.gmail.com with ESMTPSA id b131sm17623318qkc.121.2020.08.17.08.26.06 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 17 Aug 2020 08:26:07 -0700 (PDT) Date: Mon, 17 Aug 2020 11:26:04 -0400 From: Nick Rosbrook To: Anthony PERARD Cc: xen-devel@lists.xenproject.org, george.dunlap@citrix.com, Nick Rosbrook , Ian Jackson , Wei Liu Subject: Re: [RFC PATCH 1/2] libxl: add Function class to IDL Message-ID: <20200817152604.GA6441@four> References: <7e1774dffe69c702f738566abeb04a3a9d29e21b.1595854292.git.rosbrookn@ainfosec.com> <20200814105233.GD2024@perard.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200814105233.GD2024@perard.uk.xensource.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Aug 14, 2020 at 11:52:33AM +0100, Anthony PERARD wrote: > 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 > > --- > > > > +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? > Yes, I think that is much better. > > + """ > > +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? That's a good point. Do you think it would make sense to add `Builtin` definitions to libxl_types.idl for `libxl_asyncop_how`, `libxl_asyncprogress_how`, etc.? That way the generation scripts could work with those types more easily. But, I guess since those definitions aren't known until parse time we couldn't use them in the `DeviceFunction` class definition (but maybe that's not a big deal). Thank you for the feedback. -NR