search for: rhashtabl

I've discovered that libguestfs apis which return RHashtable are currently returned as a list of tuples in the python bindings rather than the obvious dict. I propose fixing this, whilst also maintaining API compatibility for a period of time. The following apis return RHashtable: inspect_get_mountpoints list_filesystems inspect_get_drive_mappings tune2fs...

If we want to permit more than 255 drives to be added, then we will have to add the disks to the same virtio-scsi target using different unit (LUN) numbers. Unfortunately SCSI LUN enumeration in the Linux is not deterministic (eg. two disks with target=0, lun=[0,1] can be enumerated as /dev/sda or /dev/sdb randomly). Dealing with that will require some very complex device name translation on the

...a/generator/actions_core.ml b/generator/actions_core.ml index db1411ff8..070a1c641 100644 --- a/generator/actions_core.ml +++ b/generator/actions_core.ml @@ -6606,6 +6606,7 @@ List all Linux md devices." }; { defaults with name = "md_detail"; added = (1, 15, 6); style = RHashtable (RPlainString, RPlainString, "info"), [String (Device, "md")], []; + impl = OCaml "Md.md_detail"; optional = Some "mdadm"; shortdesc = "obtain metadata for an MD device"; longdesc = "\ diff --git a/generator/daemon.ml b/gener...

Since commit 19e3a9c90c53 ("net: bridge: convert multicast to generic rhashtable") this is not used, so can remove it. Signed-off-by: YueHaibing <yuehaibing at huawei.com> --- net/bridge/br_private.h | 1 - 1 file changed, 1 deletion(-) diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h index 51e4ca54b537..a1f4acfa6994 100644 --- a/net/bridge/br_priva...

...} diff --git a/generator/actions.ml b/generator/actions.ml index 9c34463..287d7f5 100644 --- a/generator/actions.ml +++ b/generator/actions.ml @@ -11336,6 +11336,18 @@ silently create an ext2 filesystem instead." }; name = "list_disk_labels"; added = (1, 19, 49); style = RHashtable "labels", [], []; proc_nr = Some 369; + tests = [ + (* The test disks have no labels, so we can be sure there are + * no labels. See in tests/disk-labels/ for tests checking + * for actual disk labels. + * + * Also, we make use of the assumption that...

...n_stubs actions () = | RBool _ -> pr " int r;\n" | RConstString _ | RConstOptString _ -> failwithf "RConstString|RConstOptString cannot be used by daemon functions" - | RString _ -> pr " char *r;\n" - | RStringList _ | RHashtable _ -> pr " char **r;\n" - | RStruct (_, typ) -> pr " guestfs_int_%s *r;\n" typ - | RStructList (_, typ) -> pr " guestfs_int_%s_list *r;\n" typ + | RString _ -> pr " CLEANUP_FREE char *r = NULL;\n" + | RStringList _ | RH...

...uot;guestfs-internal-actions.h\" #include \"guestfs_protocol.h\" #include \"errnostring.h\" +#include \"structs-print.h\" "; @@ -1623,7 +1624,7 @@ and generate_client_actions hash () = let needs_i = match ret with - | RStringList _ | RHashtable _ -> true + | RStringList _ | RHashtable _ | RStructList _ -> true | _ -> false in if needs_i then ( pr "%s size_t i;\n" indent; @@ -1656,15 +1657,25 @@ and generate_client_actions hash () = pr "%s }\n" indent; pr "%s...

A malicious actor behind one bridge port may spam the kernel with packets with a random source MAC address, each of which will create an FDB entry, each of which is a dynamic allocation in the kernel. There are roughly 2^48 different MAC addresses, further limited by the rhashtable they are stored in to 2^31. Each entry is of the type struct net_bridge_fdb_entry, which is currently 128 bytes big. This means the maximum amount of memory allocated for FDB entries is 2^31 * 128B = 256GiB, which is too much for most computers. Mitigate this by adding a bridge netlink setting IF...

RConstOptString cannot return an error in the C api. This makes it a special case for the GObject api, as all other return types have a corresponding GError **err argument to return an error. This change removes this special case, and includes the possibility of an error return in the API. An error is indicated by setting *err to a non-NULL value. This change is in preparation for adding a close

...gt; "Optional[str]" + | RConstString _ | RString _ -> "str" + | RBufferOut _ -> "bytes" + | RStringList _ -> "List[str]" + | RStruct _ -> "dict" + | RStructList _ -> "List[dict]" + | RHashtable _ -> "Union[List[Tuple[str, str]], dict]" in + let type_hint_of_argt arg = + match arg with + | String _ -> ": str" + | OptString _ -> ": Optional[str]" + | Bool _ -> ": bool" + | Int _ | Int64 _ -> &quo...

..." (*%s, error)" sn; sprintf "&%s{}, " sn | RStructList (_, sn) -> let sn = camel_name_of_struct sn in - pr " (*[]%s, *GuestfsError)" sn; + pr " (*[]%s, error)" sn; "nil, " - | RHashtable _ -> pr " (map[string]string, *GuestfsError)"; "nil, " - | RBufferOut _ -> pr " ([]byte, *GuestfsError)"; "nil, " in + | RHashtable _ -> pr " (map[string]string, error)"; "nil, " + | RBufferOut _ -> pr &qu...

...ns_core.ml +++ b/generator/actions_core.ml @@ -209,43 +209,6 @@ If the mountable does not represent a btrfs subvolume, then this function fails and the C<errno> is set to C<EINVAL>." }; { defaults with - name = "list_filesystems"; added = (1, 5, 15); - style = RHashtable (RMountable, RPlainString, "fses"), [], []; - shortdesc = "list filesystems"; - longdesc = "\ -This inspection command looks for filesystems on partitions, -block devices and logical volumes, returning a list of C<mountables> -containing filesystems and their t...

...; A malicious actor behind one bridge port may spam the kernel with packets > with a random source MAC address, each of which will create an FDB entry, > each of which is a dynamic allocation in the kernel. > > There are roughly 2^48 different MAC addresses, further limited by the > rhashtable they are stored in to 2^31. Each entry is of the type struct > net_bridge_fdb_entry, which is currently 128 bytes big. This means the > maximum amount of memory allocated for FDB entries is 2^31 * 128B = > 256GiB, which is too much for most computers. > > Mitigate this by adding a...

Hi, Pino 在 2015年06月18日 16:41, Pino Toscano 写道: > Hi, > > On Thursday 18 June 2015 11:01:37 Cao jin wrote: >>> Speaking of this: you said that you have a colleague working on >>> btrfs-progs? What about suggesting to create some machine-parseable >>> output (csv, xml, yaml, json, whatever) so extracting the results of >>> btrfs tools is a lot more easy?

...match fst style with + | RErr -> false + | RConstString _ | RConstOptString _ -> failwithf "RConstString|RConstOptString cannot be used by daemon functions" - | RInt _ | RInt64 _ - | RBool _ | RString _ | RStringList _ - | RStruct _ | RStructList _ - | RHashtable _ | RBufferOut _ -> + | RInt _ | RInt64 _ + | RBool _ | RString _ | RStringList _ + | RStruct _ | RStructList _ + | RHashtable _ | RBufferOut _ -> pr " struct %s_ret ret;\n" name; - true in + true in pr " int se...

...'); - -v = g.internal_test_rstructlist('5'); -eq = v.length == 5; -for (var i = 0; eq && i < 5; i++) { - if (v[i].pv_size != i) eq = false; -} -eq || eq_fail('internal_test_rstructlist', v); -check_error('internal_test_rstructlisterr'); - -v = g.internal_test_rhashtable('5'); -eq = true; -for (var i = 0; eq && i < 5; i++) { - if (v[i] != i) eq = false; -} -eq || eq_fail('internal_test_rhashtable', v); -check_error('internal_test_rhashtableerr'); - -v = g.internal_test_rbufferout("01234"); -eq = v.length == 5; -for (va...

...n;\n" n n; pr " return p;\n"; - pr " }\n"; + pr " }\n"; ); pr "}\n\n" @@ -5592,18 +5592,18 @@ and generate_daemon_actions () = | RConstString _ | RConstOptString _ | RString _ | RStringList _ | RHashtable _ | RStruct (_, _) | RStructList (_, _) -> - pr " if (r == %s)\n" error_code; - pr " /* do_%s has already called reply_with_error */\n" name; - pr " goto done;\n"; - pr "\n" + pr " if (r == %s)\n" error_code...

...bust_spinlocks.o hexdump.o kasprintf.o bitmap.o scatterlist.o \ - gcd.o lcm.o list_sort.o uuid.o flex_array.o iovec.o clz_ctz.o \ + gcd.o lcm.o list_sort.o uuid.o flex_array.o clz_ctz.o \ bsearch.o find_last_bit.o find_next_bit.o llist.o memweight.o kfifo.o \ percpu-refcount.o percpu_ida.o rhashtable.o reciprocal_div.o obj-y += string_helpers.o diff --git a/lib/iovec.c b/lib/iovec.c deleted file mode 100644 index d8f17a9..0000000 --- a/lib/iovec.c +++ /dev/null @@ -1,36 +0,0 @@ -#include <linux/uaccess.h> -#include <linux/export.h> -#include <linux/uio.h> - -/* - * Copy iove...

...bust_spinlocks.o hexdump.o kasprintf.o bitmap.o scatterlist.o \ - gcd.o lcm.o list_sort.o uuid.o flex_array.o iovec.o clz_ctz.o \ + gcd.o lcm.o list_sort.o uuid.o flex_array.o clz_ctz.o \ bsearch.o find_last_bit.o find_next_bit.o llist.o memweight.o kfifo.o \ percpu-refcount.o percpu_ida.o rhashtable.o reciprocal_div.o obj-y += string_helpers.o diff --git a/lib/iovec.c b/lib/iovec.c deleted file mode 100644 index d8f17a9..0000000 --- a/lib/iovec.c +++ /dev/null @@ -1,36 +0,0 @@ -#include <linux/uaccess.h> -#include <linux/export.h> -#include <linux/uio.h> - -/* - * Copy iove...

This is the first iteration of the GObject bindings. I have 'kicked the tyres' on these, meaning I have ensured that a bunch of basic manual tests work as expected. I'm in the process of adding more comprehensive tests. Here's an example simple javascript program which uses these bindings: === const Guestfs = imports.gi.Guestfs; print('Starting'); var g = new