search for: cbmutabl

...urns data that is saved in the handle from the NBD protocol handshake." +(* Closures. *) +let chunk_closure = { + cbname = "chunk"; + cbargs = [ CBBytesIn ("subbuf", "count"); + CBUInt64 "offset"; CBUInt "status"; + CBMutable (Int "error") ] +} +let completion_closure = { + cbname = "completion"; + cbargs = [ CBMutable (Int "error") ] +} +let debug_closure = { + cbname = "debug"; + cbargs = [ CBString "context"; CBString "msg" ] +} +let extent_closure = {...

...pr " PyObject *py_%s = PyList_New (%s);\n" n len; + pr " for (size_t i = 0; i < %s; ++i)\n" len; + pr " PyList_SET_ITEM (py_%s, i, PyLong_FromUnsignedLong (%s[i]));\n" n n + | CBBytesIn _ + | CBInt _ + | CBInt64 _ -> () + | CBMutable (Int n) -> + pr " PyObject *py_%s_modname = PyUnicode_FromString (\"ctypes\");\n" n; + pr " if (!py_%s_modname) { PyErr_PrintEx (0); return -1; }\n" n; + pr " PyObject *py_%s_mod = PyImport_Import (py_%s_modname);\n" n n; +...

...s and quite a bit of unreachable code (eg. Python code for handling ArrayAndLen in normal methods that was never used). The output of the generator after this commit should be identical. It's possible to go a little further if we wanted: CBArrayAndLen is only ever used for ‘uint32_t’ arrays. CBMutable is only ever used for ‘int*’. We could make CB* types which only handle those cases. --- generator/generator | 428 +++++++++++++++++++------------------------- 1 file changed, 186 insertions(+), 242 deletions(-) diff --git a/generator/generator b/generator/generator index 51f2a47..88c8fef 1007...

Patches 1-4 are basically uncontroversial, straightforward refactoring and IMHO we should just push them. Possibly 1-3 should be squashed together, but I posted them separately so they are easier to review. Patches 5 and 6 together implement OClosure. Patch 5 adds the feature and is simple to understand. Patch 6 changes the Closure completion callbacks into OClosure, but because it doesn't

These are some simplifications to the generator. They don't probably make much sense on their own, but they are preparatory to better handling of enums, and or'd lists of flags. Rich.

...1407,8 +1410,8 @@ protocol extensions)."; Closure { cbname="chunk"; cbargs=[CBBytesIn ("subbuf", "count"); CBUInt64 "offset"; CBUInt "status"; - CBMutable (Int "error")] }; - Flags "flags" ]; + CBMutable (Int "error")] } ]; + optargs = [ OFlags "flags" ]; ret = RErr; permitted_states = [ Connected ]; shortdesc = "read from the NBD server"; @...

...dLen in normal methods that was > never used). Or having a closure arg within a callback. > > The output of the generator after this commit should be identical. > > It's possible to go a little further if we wanted: CBArrayAndLen is > only ever used for ‘uint32_t’ arrays. CBMutable is only ever used for > ‘int*’. We could make CB* types which only handle those cases. > --- > generator/generator | 428 +++++++++++++++++++------------------------- > 1 file changed, 186 insertions(+), 242 deletions(-) > Relatively large, but does look like a simplification....

...tdesc = "read from the NBD server"; @@ -1411,7 +1427,7 @@ protocol extensions)."; cbargs=[CBBytesIn ("subbuf", "count"); CBUInt64 "offset"; CBUInt "status"; CBMutable (Int "error")] } ]; - optargs = [ OFlags "flags" ]; + optargs = [ OFlags ("flags", cmd_flags) ]; ret = RErr; permitted_states = [ Connected ]; shortdesc = "read from the NBD server"; @@ -1485,7 +1501,7 @@ actually obeys the flag.";...

This largish series adds several new features to the generator. Enum maps to enumerated types (like enum in C). The only current use for this is replacing the nbd_set_tls (nbd, 0/1/2) parameter with LIBNBD_TLS_DISABLE, LIBNBD_TLS_ALLOW, LIBNBD_TLS_REQUIRE (and natural equivalents in other programming languages). Flags maps to any uint32_t bitmask. It is basically a non-optional, generalized

This feature is roughly finished now, although it needs a few more tests and some examples. It's pretty much up to par with all the other bindings, but it lacks a completely safe AIO buffer. It won't stop you from freeing the buffer too early) because golang's GC inexplicably lacks a way to declare a root from C. I can probably do it with a global variable and ref counting on the

Now runs a complete set of tests, notably including the AIO test. File descriptors are passed in and out as plain ints (instead of *os.File) for a couple of reasons: (1) We have to pass the plain int to syscall.Select. (2) Turning an fd into an os.File causes golang to set the blocking flag which is deeply unhelpful. Rich.

...*py_%s = PyList_New (%s);\n" n len; + pr " for (size_t i = 0; i < %s; ++i)\n" len; + pr " PyList_SET_ITEM (py_%s, i, PyLong_FromUnsignedLong (%s[i]));\n" n n | CBBytesIn _ | CBInt _ | CBInt64 _ -> () | CBMutable (Int n) -> - pr " PyObject *py_%s_modname = PyUnicode_FromString (\"ctypes\");\n" n; - pr " if (!py_%s_modname) { PyErr_PrintEx (0); return -1; }\n" n; - pr " PyObject *py_%s_mod = PyImport_Import (py_%s_modname);\n&qu...

...n + pr " PyObject *py_%s = PyList_New (%s);\n" n len; + pr " for (size_t i = 0; i < %s; ++i)\n" len; + pr " PyList_SET_ITEM (py_%s, i, PyLong_FromUnsignedLong (%s[i]));\n" n n | CBBytesIn _ | CBInt _ | CBInt64 _ -> () | CBMutable (Int n) -> - pr " PyObject *py_%s_modname = PyUnicode_FromString (\"ctypes\");\n" n; - pr " if (!py_%s_modname) { PyErr_PrintEx (0); return -1; }\n" n; - pr " PyObject *py_%s_mod = PyImport_Import (py_%s_modname);\n" n n; -...

Still not working, but I took the latest patch and: - rebased it against libnbd 1.0 - fixed it so it handles new args and cbargs The generator now runs without warnings. This patch doesn't handle optargs at all. In C these are converted to non-optional parameter. Rust doesn't (AFAIK) have optional or labelled arguments unfortunately. Rich.

As proposed here: https://www.redhat.com/archives/libguestfs/2019-August/msg00130.html I didn't actually read Eric's replies to that yet because I've been concentrating on writing these patches all day. Anyway here they are and I'll look at what Eric said about the proposal next. Rich.

Patches 1 & 2 are rather complex, but the end result is that we pass closures + user_data + free function in single struct parameters as I described previously in this email: https://www.redhat.com/archives/libguestfs/2019-August/msg00210.html Patch 3 adds a convenient FREE_CALLBACK macro which seems a worthwhile simplification if you buy into 1 & 2. Patch 4 adds another macro which is

...tern const char *nbd_internal_name_of_nbd_cmd (uint16_t type); diff --git a/generator/API.ml b/generator/API.ml index c660960..52970d3 100644 --- a/generator/API.ml +++ b/generator/API.ml @@ -127,8 +127,12 @@ let extent_closure = { "nr_entries"); CBMutable (Int "error") ] } +let list_closure = { + cbname = "list"; + cbargs = [ CBString "name"; CBString "description" ] +} let all_closures = [ chunk_closure; completion_closure; - debug_closure; extent_closure ] + debug...

This doesn't yet work. However it does make me more convinced than ever that we really need to sort out persistent buffer lifetimes in the library (similar to what we did for closures). Rich.

...tern const char *nbd_internal_name_of_nbd_cmd (uint16_t type); diff --git a/generator/API.ml b/generator/API.ml index a5c253a..76e9793 100644 --- a/generator/API.ml +++ b/generator/API.ml @@ -127,8 +127,12 @@ let extent_closure = { "nr_entries"); CBMutable (Int "error") ] } +let list_closure = { + cbname = "list"; + cbargs = [ CBString "name"; CBString "description" ] +} let all_closures = [ chunk_closure; completion_closure; - debug_closure; extent_closure ] + debug...

This is a subset of my v2 posting, but limited to just the NBD_OPT_LIST handling. The biggest change since v2 is the addition of added unit testing in all four language bindings (C, python, ocaml, golang). The tests require nbdkit built from git on PATH, and may not be entirely idiomatic, but I at least validated that they catch issues (for example, adding an exit statement near the end of the