From: Nick Rosbrook
These functions now have a third parameter of type const *libxl_asyncop_how.
Pass nil for this argument to fix compilation and maintain the
synchronous behavior.
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/xenlight.go | 4 ++--
1 file changed, 2 insertions
> Actually this has already been submitted and Release-acked here:
>
> https://patchew.org/Xen/20191023162358.7222-1-george.dun...@citrix.com/
Ah thanks, I remember seeing that now but I confused it with the
*very* similar patch for libxl_domain_pause/unpause.
-NR
___
> If we do have to keep the C pointer around for some reason, I think
> using SetFinalizer is a necessary backstop to keep the library from
> leaking. It's all well and good to say, "Make sure you call Dispose()",
> but I think for a GC'd language that's just going to be too easy to
> forget; and
On Fri, Sep 04, 2020 at 05:40:00PM +0100, George Dunlap wrote:
> Remove all go files and generation targets.
>
> Add a convenience macro to build the package from staging. This isn't
> really meant to be called directly; rather, it's meant to be called
> from a corresponding build target inside t
On Tue, Sep 08, 2020 at 08:46:58PM +, George Dunlap wrote:
>
>
> > On Sep 8, 2020, at 6:03 PM, Nick Rosbrook wrote:
> >
> > On Fri, Sep 04, 2020 at 05:40:00PM +0100, George Dunlap wrote:
> >> Remove all go files and generation targets.
> >>
absolute path to libxl_types.idl, therefore creating
unintended diffs when generating code across different machines. This
approach fixes that problem.
[1] https://github.com/golang/go/issues/13560
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/gengotypes.py | 10 --
tools/golang
_ROOT when calling gengotypes.py.
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/Makefile | 2 +-
tools/golang/xenlight/gengotypes.py | 9 -
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
index
Add DeviceNicAdd and DeviceNicRemove as wrappers for
libxl_device_nic_add and libxl_device_nic_remove.
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/xenlight.go | 34 +++
1 file changed, 34 insertions(+)
diff --git a/tools/golang/xenlight/xenlight.go
b
Add DevicePciAdd and DevicePciRemove as wrappers for
libxl_device_pci_add and libxl_device_pci remove.
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/xenlight.go | 34 +++
1 file changed, 34 insertions(+)
diff --git a/tools/golang/xenlight/xenlight.go
b
have started an experimental branch where I am using these
functions in redctl [1].
[1]
https://gitlab.com/enr0n/redctl/-/blob/1bdf7b515654cc030e095f3a630a24530f930c00/internal/server/xenlight_xen_driver.go
Nick Rosbrook (4):
golang/xenlight: add NameToDomid and DomidToName util functions
Many exported functions in xenlight require a domid as an argument. Make
it easier for package users to use these functions by adding wrappers
for the libxl utility functions libxl_name_to_domid and
libxl_domid_to_name.
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/xenlight.go | 23
Add DeviceUsbdevAdd and DeviceUsbdevRemove as wrappers for
libxl_device_usbdev_add and libxl_device_usbdev_remove.
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/xenlight.go | 34 +++
1 file changed, 34 insertions(+)
diff --git a/tools/golang/xenlight
> One question I have from the above is how the xen.git RELEASE-X.Y.Z should
> correspond to the vA.B.C in the golang package repo.
>
> The obvious answer, of course, is (A, B, C) = (X, Y, Z); that is, xen.git tag
> RELEASE-4.14.0 should create a golang package tag of v4.14.0.
>
> The issue with
> libxl.h defines INVALID_DOMID — do we want to define an exported constant
> with the same name and use that here? (Although part of me wonders if
> DOMID_INVALID would be a better option.)
Yeah, that makes sense. I'll add that.
> > + }
> > +
> > + return Domid(domid), nil
> > +}
> >
> I feel like I want to say here what it is you actually have to fill in to
> remove the nic; but after 10 minutes of poking around the code, I’m not
> actually sure myself. :-) (I think it *might* be just Devid and
> BackendDomid.)
IIRC, you can use just the MAC or devid. I was using just the
These patches add support for the golang tools in the build system.
The behavior of configure with respect to the new variable,
CONFIG_GOLANG_TOOLS is copied from other components, such as the Ocaml
tools. Namely, build the tools by default if the go compiler is found.
Nick Rosbrook (2):
tools
/Rules.mk since the new variable is set by
configure.
Signed-off-by: Nick Rosbrook
---
config/Tools.mk.in | 1 +
m4/golang.m4 | 4 ++
tools/Makefile | 2 +-
tools/Rules.mk | 2 -
tools/configure| 138 +
tools/configure.ac | 12
On Thu, Apr 23, 2020 at 6:22 AM George Dunlap wrote:
>
>
>
> > On Apr 12, 2020, at 11:02 PM, Nick Rosbrook wrote:
> >
> > Add DevicePciAdd and DevicePciRemove as wrappers for
> > libxl_device_pci_add and libxl_device_pci remove.
> >
> > Signed-o
On Thu, Apr 23, 2020 at 9:44 AM George Dunlap wrote:
>
>
>
> On Thu, Apr 23, 2020 at 1:51 AM Nick Rosbrook wrote:
>>
>> By default, if the go compiler is found by the configure script, build
>> the golang tools. If the compiler is not found, and
>> --enable
On Thu, Apr 23, 2020 at 6:25 AM Wei Liu wrote:
>
> On Wed, Apr 22, 2020 at 08:25:25PM -0400, Nick Rosbrook wrote:
> > By default, if the go compiler is found by the configure script, build
> > the golang tools. If the compiler is not found, and
> > --enable-golang_tools wa
> The underscore thing though — I think it’s a bad idea to mix `-` and `_`;
> —enable-golang_tools just isn’t a good idea IMHO. :-)
>
> Do you need _tools? Could it just be —enable-golang?
I agree, I don't like mixing the '-' and '_'. From what I could tell,
that was how the other options were n
Many exported functions in xenlight require a domid as an argument. Make
it easier for package users to use these functions by adding wrappers
for the libxl utility functions libxl_name_to_domid and
libxl_domid_to_name.
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/xenlight.go | 38
more detail to function comments
Nick Rosbrook (1):
golang/xenlight: add NameToDomid and DomidToName util functions
tools/golang/xenlight/xenlight.go | 38 ++-
1 file changed, 37 insertions(+), 1 deletion(-)
--
2.17.1
variable to CONFIG_GOLANG, and use `golang` rather
than golang_tools to avoid mixing underscores and hyphens in
configure flags.
Nick Rosbrook (2):
tools: build golang tools if go compiler is present
golang/xenlight: stop tracking generated files
.gitignore
variable is now set by configure in
config/Tools.mk.
Signed-off-by: Nick Rosbrook
Acked-by: Wei Liu
---
config/Tools.mk.in | 1 +
m4/golang.m4 | 4 ++
tools/Rules.mk | 2 -
tools/configure| 138 +
tools/configure.ac | 12
5
On Thu, Apr 23, 2020 at 1:22 PM George Dunlap wrote:
>
>
> > On Apr 23, 2020, at 12:49 PM, George Dunlap
> > wrote:
> >
> >
> >
> >> On Apr 23, 2020, at 12:27 PM, Ian Jackson wrote:
> >>
> >> Ian Jackson writes ("Re: Golang Xen packages and the golang packaging
> >> system"):
> >>> This is qu
On Fri, Apr 24, 2020 at 7:26 AM George Dunlap wrote:
>
>
>
> > On Apr 24, 2020, at 5:04 AM, Nick Rosbrook wrote:
> >
> > On Thu, Apr 23, 2020 at 1:22 PM George Dunlap
> > wrote:
> >>
> >>
> >>> On Apr 23, 2020, at 12:49 PM, George
On Mon, Apr 27, 2020 at 8:59 AM George Dunlap wrote:
>
>
>
> > On Apr 24, 2020, at 4:02 AM, Nick Rosbrook wrote:
> >
> > Many exported functions in xenlight require a domid as an argument. Make
> > it easier for package users to use these functions by adding w
> BTW the separate repo isn’t off the table. But there were some things other
> Ian pointed out:
After trying (and failing) to get a go module with a remote import
path like `golang.xenproject.org/xenlight` defined in xen.git, I would
like to circle back to the separate repo.
In theory, modules
properly on pkg.go.dev and be available via the module
proxy at proxy.golang.org.
Nick Rosbrook (3):
golang/xenlight: re-track generated go code
golang/xenlight: init xenlight go module
golang/xenlight: add necessary module/package documentation
.gitignore |3
Initialize the xenlight Go module using the xenbits git-http URL,
xenbits.xen.org/git-http/xen.git/tools/golang/xenlight, and update the
XEN_GOCODE_URL variable in tools/Rules.mk accordingly.
Signed-off-by: Nick Rosbrook
---
tools/Rules.mk | 2 +-
tools/golang/xenlight/go.mod | 1
proxy, proxy.golang.org.
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/LICENSE | 416 ++
tools/golang/xenlight/README.md | 17 ++
tools/golang/xenlight/xenlight.go | 2 +
3 files changed, 435 insertions(+)
create mode 100644 tools/golang/xenlight/LICENSE
c
> > I just tested this way, and it does not work as expected. Since
> > C.INVALID_DOMID is #define'd, cgo does not know it is intended to be
> > used as uint32_t, and decides to declare C.INVALID_DOMID as int. So,
> > C.INVALID_DOMID = ^int(0) = -1, which overflows Domid.
> >
> > I tried a few thin
On Tue, May 12, 2020 at 10:36 AM George Dunlap wrote:
>
>
>
> > On Apr 30, 2020, at 10:39 PM, Nick Rosbrook wrote:
> >
> > Initialize the xenlight Go module using the xenbits git-http URL,
> > xenbits.xen.org/git-http/xen.git/tools/golang/xenlight, and update t
> For trademark reasons, when we joined the Linux Foundation, we did a big
> rebranding from “Xen” to “XenProject”. (See [1] for more details.) The
> xen.org domains are just for backwards compatibility. :-)
Ah, thanks! I'll fix that.
-NR
On Tue, May 12, 2020 at 1:20 PM George Dunlap wrote:
>
>
>
> > On Apr 30, 2020, at 10:39 PM, Nick Rosbrook wrote:
> >
> > Add a README and package comment giving a brief overview of the package.
> > These also help pkg.go.dev generate better documentation.
> The whole point of running ‘go build’ is to make sure that *the code we just
> copied* — the code right now in our own local tree, perhaps which was just
> generated — actually compiles.
I understand that, and in my tests that's the outcome.
> It looks like when we add the `go.mod` further up
more detail to function comments
Changes in v3:
- Define INVALID_DOMID_TYPED in C preamble so that the Go const
DomidInvalid is always in-sync with the libxl definition.
Nick Rosbrook (1):
golang/xenlight: add NameToDomid and DomidToName util functions
tools/golang/xenlight/xenlight.go
Many exported functions in xenlight require a domid as an argument. Make
it easier for package users to use these functions by adding wrappers
for the libxl utility functions libxl_name_to_domid and
libxl_domid_to_name.
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/xenlight.go | 40
package in SUPPORT.md.
- Change some wording in the README for clarity.
Nick Rosbrook (3):
golang/xenlight: re-track generated go code
golang/xenlight: init xenlight go module
golang/xenlight: add necessary module/package documentation
.gitignore |3
Initialize the xenlight Go module using the xenbits git-http URL,
xenbits.xenproject.org/git-http/xen.git/tools/golang/xenlight.
Also simplify the build Make target by using `go build` instead of `go
install`, and do not set GOPATH here because it is now unnecessary.
Signed-off-by: Nick Rosbrook
default module proxy, proxy.golang.org.
Finally, add an entry for the xenlight package to SUPPORT.md.
Signed-off-by: Nick Rosbrook
---
Changes in v2:
- Use LGPL instead of GPL for license.
- Change some wording in README for clarity.
- Add entry to SUPPORT.md for xenlight package
kage to be shown
> > on pkg.go.dev and added to the default module proxy, proxy.golang.org.
> >
> > Finally, add an entry for the xenlight package to SUPPORT.md.
> >
> > Signed-off-by: Nick Rosbrook
>
> Reviewed-by: George Dunlap
Thanks!
-NR
> OK, so didn’t notice this at first. It looks like you read the comments at
> the top of libxl.c, noticed the comment about “...the special exception on
> linking described in file LICENSE”, looked around for such a file, and found
> it in tools/ocaml, and copied that one?
>
> I had a chat wit
default module proxy, proxy.golang.org.
Finally, add an entry for the xenlight package to SUPPORT.md.
Signed-off-by: Nick Rosbrook
---
Changes in v2:
- Use LGPL instead of GPL for license.
- Change some wording in README for clarity.
- Add entry to SUPPORT.md for xenlight package.
Changes in v3
package in SUPPORT.md.
- Change some wording in the README for clarity.
Changes in v3:
- Use LGPL as-is from [1].
- Wrap lines in README.
[1] https://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt
Nick Rosbrook (1):
golang/xenlight: add necessary module/package documentation
SUPPORT.md
Generate constructors for generated Go types. Call libxl__init so
the Go type can be properly initialized.
If a type has a keyed union field, add a parameter to the function
signature to set the key variable, and call the init function for the
keyed union.
Signed-off-by: Nick Rosbrook
> Generate constructors for generated Go types. Call libxl__init so
> the Go type can be properly initialized.
>
> If a type has a keyed union field, add a parameter to the function
> signature to set the key variable, and call the init function for the
> keyed union.
>
> Although, I'm not sure if that implies "There's already boilerplate, so
> it's extra important to avoid adding more", or "There's already
> boilerplate, so it won't hurt to have a bit more, and wrap the whole
> thing in a nicer library."
I think the boilerplate added here is necessary. We need t
> NewDomainConfig() as of this patch can never return success, because
> DomainConfig.fromC() will call DomainBuildInfo.fromC(), which will choke
> on b_info.type = LIBXL_DOMAIN_TYPE_INVALID.
>
> This is actually a bug in to/fromC. Consider libxl_channelinfo.
>
> The idl says:
>
> libxl_channelinf
ks rather than do a copy; so make a global
> structure in C space. Make it `static const`, just for extra safety;
> this requires making a function in the C space to pass it to libxl.
>
> While here, add a few comments to make the context set-up a bit easi
{
Capitalizing "Ctx" here is a little weird to me. Since it's only the
receiver name, there's no effect, but since capitalized identifiers
have special-meaning in other contexts, I would avoid doing this.
I only point those out in case you w
On Fri, Oct 16, 2020 at 04:29:58PM +, George Dunlap wrote:
> https://gitlab.com/martyros/go-xen branch `working/xenops` contains a
> super-basic mock-up of a unix domain xenopsd based on the golang libxl
> bindings.
>
> To use:
>
> * Install Xen >= 4.14 on your target system
>
> * Make sur
> The current fromC array code will do the "magic" casting and
> martialling even when num_foo variable is 0. Go crashes when doing
> the cast.
>
> Furthermore, the current toC array code will convert a nil slice into
> a zero-length malloc. The resulting pointer is non-NULL, and confuses
> libxl
On Fri, Dec 27, 2019 at 11:33 AM George Dunlap wrote:
>
> Similar to the autogenerated types, but for `builtin` Bitmap type.
>
> Signed-off-by: George Dunlap
Reviewed-by: Nick Rosbrook
___
Xen-devel mailing list
Xen-devel@lists.xenproje
> C.GoString will handle NULL C strings properly, by passing back "".
> But C.CString will take an empty Go string and actually generate a
> '\0'-terminated empty string. This confuses libxl, which is expecting
> non-values to be NULL, not "".
>
> Only call C.CString if the Go string is non-empty.
it to ErrorInval.
>
> Signed-off-by: George Dunlap
Looks good to me. If "golang/xenlight: begin Go to C type marshaling"
is committed before this, the signature of toC will need to be updated
as per your suggestion.
Otherwise,
Reviewed-by: Nick Rosbrook
_
On Fri, Dec 27, 2019 at 11:33 AM George Dunlap wrote:
>
> If an error is encountered deep in a complicated data structure, it's
> often difficult to tell where the error actually is. Make the error
> message from the generated toC() and fromC() structures more
> informative by tagging which field
On Fri, Dec 27, 2019 at 11:33 AM George Dunlap wrote:
>
> Commit 871e51d2d4 changed the sign on the xenlight error types (making
> the values negative, same as the C-generated constants), but failed to
> flip the sign in the Error() string function. The result is that
> ErrorNonspecific.String()
Implement conversions for basic types such as strings and integer
types in toC functions.
Modify function signatures of toC implementations for builtin
types to be consistent with the signature of the generated toC
functions.
Signed-off-by: Nick Rosbrook
---
Changes in v5:
- Define
://github.com/enr0n/xen/tree/golang-patches-v1
[3] https://github.com/enr0n/xen/tree/golang-patches-v2
[4] https://github.com/enr0n/xen/tree/golang-patches-v3
[5] https://github.com/enr0n/xen/tree/golang-patches-v4
[6] https://github.com/enr0n/xen/tree/golang-patches-v5
Nick Rosbrook (3):
golang
Since the C union cannot be directly populated, populate the fields of the
corresponding C struct defined in the cgo preamble, and then copy that
struct as bytes into the byte slice that Go uses as the union.
Signed-off-by: Nick Rosbrook
---
Changes in v5:
- Make use of
Signed-off-by: Nick Rosbrook
---
Changes in v5:
- Remove dispose_fn from parameter list in xenlight_golang_array_to_C
since it's no longer needed.
- Update call to toC for elements of arrays of structs so that it
matches the new function signature of toC.
- Do not try to marshal zero-l
> Looks good! Only one question:
>
> > +if not is_castable:
> > +s += 'if err := x.{}.toC(&xc.{}); err != nil
> > {{\n'.format(goname,cname)
>
> Err should be defined function-wide at this point. Are you using `:=`
> on purpose for some reason? Would it make sense to make this `=` i
> // Context represents a libxl_ctx.
> type Context struct {
> - ctx*C.libxl_ctx
> - logger *C.xentoollog_logger_stdiostream
> + ctx *C.libxl_ctx
> + logger *C.xentoollog_logger_stdiostream
> + sigchld chan os.Signal
> + sigchldDone chan bo
onvert
> it to ErrorInval.
>
> Finally, make the fromC() method take a pointer, and set the value of
> CpuidPolicyList such that it will generate a valid CpuidPolicyList in
> response.
>
> Signed-off-by: George Dunlap
Reviewed-by: Nick Rosbrook
__
his case it's more difficult because they interact
> with actual code changes. I'll leave this here for now, as we're
> going to remove helpers.gen.go from being tracked by git at some point
> in the near future anyway.
>
> Signed-off-by: George Dunlap
Reviewed-by: N
Sorry I didn't catch this the first time around, but:
> diff --git a/tools/golang/xenlight/helpers.gen.go
> b/tools/golang/xenlight/helpers.gen.go
> index b9a7e828a0..889807d928 100644
> --- a/tools/golang/xenlight/helpers.gen.go
> +++ b/tools/golang/xenlight/helpers.gen.go
> @@ -623,12 +623,14
n the
> human-readable error message.
>
> Get rid of the whole issue by making libxlErrors a map, and mapping
> actual error values to string, falling back to printing the actual
> value of the Error type if it's not present.
>
> Signed-o
> The other option would be to expose the XTL logging levels and let the
> caller set them somehow.
I think this is fine for now.
For the future, I like using the "functional option" pattern for this
sort of thing. That way, if a user wanted to set a non-default log
level, they could do:
ctx, err
partially-created
> context.
>
> Signed-off-by: George Dunlap
Reviewed-by: Nick Rosbrook
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Sorry for the late reply on this one.
> +func NewDomainConfig(t DomainType) (*DomainConfig, error) {
> + var cconfig C.libxl_domain_config
> +
> + C.libxl_domain_config_init(&cconfig)
> + C.libxl_domain_build_info_init_type(&cconfig.b_info,
> C.libxl_domain_type(t))
> +
> +
> But really, we need a way to actually create a logger properly. Apparently
> one thing libvirt does is to create a logger to a file for each guest.
> That’s something our package users might want to do at some point.
Yes, I think package users will want logging to be pretty flexible. I
thin
> I think marshaling and unmarshalling should be fine, *as long as* the
> structure being unmarshalled actually went through the
> libxl__init() function first.
>
> In fact, I was kicking around the idea of adding a non-exported field to
> all the generated structs -- maybe "bool initalized" -- and
> I *think* to guarantee that libxl__init() has been called when
> unmarshaling, we would need to generate UnmarshalJSON functions to
> implement json.Unmarshaler. E.g.,:
>
> func (dd *DeviceDisk) UnmarshalJSON(data []byte) error {
> if dd == nil { // Or maybe this is the 'initialized' chec
Generate constructors for generated Go types. Call libxl__init so
the Go type can be properly initialized.
If a type has a keyed union field, add a parameter to the function
signature to set the key variable, and call the init function for the
keyed union.
Signed-off-by: Nick Rosbrook
George,
Note that without your patch "golang/xenlight: Don't try to marshall
zero-length arrays in fromC", some of these constructors will panic.
Thanks,
-NR
On Wed, Jan 29, 2020 at 7:09 PM Nick Rosbrook wrote:
>
> Generate constructors for generated Go types. Call libxl__
> But the problem I'm worried about is this:
>
> Scenario B
> 1. Make an empty, uninitialized structure, without calling NewType()
> 2. Fill in some fields
> 3. Marshal it into json
> 4. Marshal it out of json (with the same version)
>
> In the case above, step 3 encodes all the known fields with *
On Fri, Jan 22, 2021 at 01:18:01PM +, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
I think you mean "after recent" rather than "are recent" in your commit
message. But otherwise,
Acked-by: Nick Rosbrook
Thanks,
NR
Signed-off-by: Nick Rosbrook
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e374816755..33fe51324e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -298,6 +298,7 @@ F: tools/debugger/gdbsx/
GOLANG BINDINGS
M: George Dunlap
+M: Nick
hon 2.6. Use the 2.6 syntax for
format() in order to support python 2.6 for now.
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/gengotypes.py | 204 ++--
1 file changed, 102 insertions(+), 102 deletions(-)
diff --git a/tools/golang/xenlight/gengotypes.py
b/t
ere, which means
> the Go bindings do not build on python 2.6. Use the 2.6 syntax for
> format() in order to support python 2.6 for now.
>
> Signed-off-by: Nick Rosbrook
I should add that I tested this with CONTAINER=centos6
./automation/scripts/containerize for python 2.6, and on my ubuntu
system with both python 2.7 and 3.6.
-NR
Hello,
Here are the notes from the golang bindings design session at Xen Summit
earlier this month:
Possible improvements:
- Expanding the IDL to have information about device add / remove functions
Ian: It's important that the IDL generates the C prototypes as well.
We could
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
---
tools/golang/xenlight/gengotypes.py | 2 +-
tools/libxl/gentypes.py | 2 +-
tools/libxl/idl.py
Add a DeviceFunction class and describe prototypes for
libxl_device_nic_add/remove in libxl_types.idl.
Signed-off-by: Nick Rosbrook
--
This is mostly to serve as an example of how the first patch would be
used for function support in the IDL.
---
tools/libxl/idl.py | 8
tools
] https://lists.xenproject.org/archives/html/xen-devel/2020-07/msg00964.html
Nick Rosbrook (2):
libxl: add Function class to IDL
libxl: prototype libxl_device_nic_add/remove with IDL
tools/golang/xenlight/gengotypes.py | 2 +-
tools/libxl/gentypes.py | 2 +-
tools/libxl/idl.py
On Tue, Aug 4, 2020 at 10:17 AM Wei Liu wrote:
>
> On Mon, Aug 03, 2020 at 10:06:32AM +0200, Jan Beulich wrote:
> > While this doesn't address the real problem I've run into (attempting to
> > update r/o source files), not recursing into tools/golang/xenlight/ is
> > enough to fix the build for me
On Tue, Aug 4, 2020 at 12:02 PM Jan Beulich wrote:
>
> On 04.08.2020 17:57, Wei Liu wrote:
> > On Tue, Aug 04, 2020 at 05:53:49PM +0200, Jan Beulich wrote:
> >> On 04.08.2020 17:50, Wei Liu wrote:
> >>> On Tue, Aug 04, 2020 at 05:30:40PM +0200, Jan Beulich wrote:
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
>
On Fri, Aug 14, 2020 at 11:57:47AM +0100, Anthony PERARD wrote:
> On Mon, Jul 27, 2020 at 09:26:33AM -0400, Nick Rosbrook wrote:
> > Add a DeviceFunction class and describe prototypes for
> > libxl_device_nic_add/remove in libxl_types.idl.
> >
> > Signed-off-by: Nick R
On Mon, Aug 24, 2020 at 03:11:41PM +0200, Jan Beulich wrote:
> On 04.08.2020 18:41, Nick Rosbrook wrote:
> > On Tue, Aug 4, 2020 at 12:02 PM Jan Beulich wrote:
> >>
> >> On 04.08.2020 17:57, Wei Liu wrote:
> >>> On Tue, Aug 04, 2020 at 05:53:49PM +0200, Jan
On Tue, Aug 25, 2020 at 10:37:09AM +, George Dunlap wrote:
>
>
> > On Aug 25, 2020, at 7:47 AM, Jan Beulich wrote:
> >
> > On 24.08.2020 16:58, Nick Rosbrook wrote:
> >> My understanding was that you were going to use move-if-changed to fix
> >> th
g with a read-only source and
> an out-of-tree build.
>
> Signed-off-by: George Dunlap
> ---
> This is a candidate to backport for 4.14.
>
> I was doing prep for writing the infrastructure to create or update an
> external repo, and figured I might as well send this out now.
g with a read-only source and
> an out-of-tree build.
>
> Signed-off-by: George Dunlap
Acked-by: Nick Rosbrook
On Fri, Aug 28, 2020 at 07:05:08PM +, George Dunlap wrote:
>
>
> > On Aug 28, 2020, at 4:57 PM, George Dunlap wrote:
> >
> >
> >
> >> On Jul 21, 2020, at 1:35 AM, Nick Rosbrook wrote:
> >>
> >> # Long-term home of the packa
These patches make changes to the generated "keyed union" types that
allow marshaling and unmarshaling easier, specifically when using the
encoding/json package from the Go standard library.
Nick Rosbrook (2):
golang/xenlight: export keyed union interface types
golang/xenlight:
g/git-http/xen.git/tools/golang/xenlight?tab=doc#DeviceUsbdev
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/gengotypes.py | 6 +--
tools/golang/xenlight/types.gen.go | 58 ++---
2 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/tools/golan
NOT using pointers
in these fields, update code generation to set keyed union fields to
pointers of their implementing structs.
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/gengotypes.py | 4 +--
tools/golang/xenlight/helpers.gen.go | 44 ++--
2 files changed, 24
appearing as "package comments."
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/gengotypes.py | 1 +
tools/golang/xenlight/helpers.gen.go | 1 +
tools/golang/xenlight/types.gen.go | 1 +
3 files changed, 3 insertions(+)
diff --git a/tools/golang/xenlight/gengotypes.py
b/t
> When generating documentation, pkg.go.dev and godoc.org assume a comment
> that immediately precedes the package declaration is a "package
> comment", and should be shown in the documentation. Add an empty line
> after the DO NOT EDIT comment in generated files to prevent these
> comments from ap
101 - 200 of 279 matches
Mail list logo
