search for: _set

...e the level of > optimization because you know or suspect the compiler to generate wrong > code. > > What you should do, is use > PKG_CFLAGS > as documented in R-exts, 1.2.1 under "Using Makevars". in the documentation you pointed (and trust me I read it), keyword is _set additional_ preprocessor options and//or compiler flags only way to _remove_ is to overwrite back to logic. either Makevars, whatever level, allow to overwrite CC definition either Makevars, whatever level, disable CC redefinition but not a mix Eric

...nday, 29 November, 2010, Li Zefan wrote: >>> This allows us to set a snapshot readonly or writable on the fly. >>> >>> Usage: >>> >>> Set BTRFS_SNAPSHOT_RDONLY/WRITABLE of btrfs_ioctl_vol_arg_v2->flags, >>> and then call ioctl(BTRFS_IOCTL_SNAP_SETFLAGS); >> >> I really appreciate your work, but I have some doubt about this interface. In >> particolar: > >It''s the interface that I would like to be discussed. Thanks! > >> - how get the flags of a subvolume ? I suggest to implement a pair of ioctls:...

...s interface supports */ >> __u32 advertising; /* Features this interface advertises */ >> __u16 speed; /* The forced speed (lower bits) in >> * Mbps. Please use >> * ethtool_cmd_speed()/_set() to >> * access it */ >> __u8 duplex; /* Duplex, half or full */ >> __u8 port; /* Which connector port */ >> __u8 phy_address; >> __u8 transceiver; /* Which transceiver to use */ &...

...s interface supports */ >> __u32 advertising; /* Features this interface advertises */ >> __u16 speed; /* The forced speed (lower bits) in >> * Mbps. Please use >> * ethtool_cmd_speed()/_set() to >> * access it */ >> __u8 duplex; /* Duplex, half or full */ >> __u8 port; /* Which connector port */ >> __u8 phy_address; >> __u8 transceiver; /* Which transceiver to use */ &...

...>> > > > > > > > > > >> > > > > > > > > > \[2018-02-13 08:16:13.948699\] I \[MSGID: 114046\] >> > > > > > > > > > >> > > > > > > > > > \[client-handshake.c:1216:client\_setvolume\_cbk\] 0-myvolume-client-0: >> > > > > > > > > > >> > > > > > > > > > Connected to myvolume-client-0, attached to remote volume >> > > > > > > > > > >> > > > > > > > &...

...9154 (from 0) > > > > > > > > > > > > > > > > > > > > \[2018-02-13 08:16:13.948699\] I \[MSGID: 114046\] > > > > > > > > > > > > > > > > > > > > \[client-handshake.c:1216:client\_setvolume\_cbk\] 0-myvolume-client-0: > > > > > > > > > > > > > > > > > > > > Connected to myvolume-client-0, attached to remote volume > > > > > > > > > > > > > > > > > > > > '...

...gt; > > > > > > > > > > > > > > > > > > \[2018-02-13 08:16:13.948699\] I \[MSGID: 114046\] > > > > > > > > > > > > > > > > > > > > > > > > \[client-handshake.c:1216:client\_setvolume\_cbk\] 0-myvolume-client-0: > > > > > > > > > > > > > > > > > > > > > > > > Connected to myvolume-client-0, attached to remote volume > > > > > > > > > > > > > > > > >...

...use you know or suspect the compiler to generate wrong >> code. >> >> What you should do, is use >> PKG_CFLAGS >> as documented in R-exts, 1.2.1 under "Using Makevars". >> > > in the documentation you pointed (and trust me I read it), keyword is _set > additional_ preprocessor options and//or compiler flags > > only way to _remove_ is to overwrite > > back to logic. > > either Makevars, whatever level, allow to overwrite CC definition > either Makevars, whatever level, disable CC redefinition > > but not a mix &gt...

...settings.c --- a/src/master/master-settings.c Wed Jan 21 02:21:35 2015 +0200 +++ b/src/master/master-settings.c Thu Jan 22 13:39:41 2015 +0200 @@ -18,6 +18,7 @@ #include <unistd.h> #include <sys/stat.h> #include <sys/wait.h> +#include <sys/resource.h> static bool master_settings_verify(void *_set, pool_t pool, const char **error_r); @@ -418,7 +419,7 @@ #ifdef CONFIG_BINARY const struct service_settings *default_service; #else - rlim_t fd_limit; + struct rlimit fd_limit; const char *max_client_limit_source = "default_client_limit"; unsigned in...

...les changed, 12 insertions(+), 2 deletions(-) diff --git a/src/lib-master/master-service-settings.c b/src/lib-master/master-service-settings.c index 30ad936..67fca19 100644 --- a/src/lib-master/master-service-settings.c +++ b/src/lib-master/master-service-settings.c @@ -36,6 +36,7 @@ master_service_settings_check(void *_set, pool_t pool, const char **error_r); static const struct setting_define master_service_setting_defines[] = { DEF(SET_STR, base_dir), DEF(SET_STR, state_dir), + DEF(SET_STR, instance_name), DEF(SET_STR, log_path), DEF(SET_STR, info_log_path), DEF(SET_STR, debug_log_p...

Hello, When running multiple instances of dovecot on the same host (or running multiple docker container), it is hard to distinguish logs from different processes: the syslog entries are all prefixed with the same identifier "dovecot" It is hardcoded here: https://github.com/dovecot/core/blob/master/src/lib-master/master-service.c#L420 Would it make sense to use the already implemented

...13 08:16:13.948579] I [rpc-clnt.c:2000:rpc_clnt_reconfig] >>>>>>>>> 0-myvolume-client-1: changing port to 49154 (from 0) >>>>>>>>> [2018-02-13 08:16:13.948699] I [MSGID: 114046] >>>>>>>>> [client-handshake.c:1216:client_setvolume_cbk] 0-myvolume-client-0: >>>>>>>>> Connected to myvolume-client-0, attached to remote volume >>>>>>>>> '/data/myvolume/brick'. >>>>>>>>> [2018-02-13 08:16:13.948747] I [MSGID: 114047] >>>>&gt...

...rror due to bash tests: regression: test masquerade from nat/postrouting too datatype: fix crash when using basetype instead of symbolic constants datatype: relax datatype check in integer_type_parse() netlink_delinearize: clone on netlink_get_register(), release previous on _set() meta: set base field on clones tests: regression: fix "Listing is broken" instead of output mismatch tests: regression: any/ct: remove wrong output scanner: don't bug on too large values payload: fix endianess issue in payload_expr_pctx_update() s...

..._instance *inst; - const char *pidfile_path; + const char *instance_path, *pidfile_path; bool show_config = FALSE; int c; @@ -71,7 +71,8 @@ doveadm_print_header_simple("running"); } - list = master_instance_list_init(MASTER_INSTANCE_PATH); + instance_path = t_strconcat(doveadm_settings->state_dir, "/instances", NULL); + list = master_instance_list_init(instance_path); iter = master_instance_list_iterate_init(list); while ((inst = master_instance_iterate_list_next(iter)) != NULL) { if (argv[0] != NULL && strcmp(argv[0], inst->name) != 0) @@ -99,...

Le 27/09/16 ? 13:31, Dirk Eddelbuettel a ?crit : > > On 27 September 2016 at 09:37, Eric Deveaud wrote: > | Hello, > | > | I'm tring to install a Rpackage that holds some C//C++ code > | > | as far as I understood the R library generic compilation mechanism, > | compilation of C//C++ sources is controled > | > | 1) at system level by the ocntentos

...getable state before starting to set any ptes. */ diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h index b095739..7eee651 100644 --- a/arch/x86/xen/xen-ops.h +++ b/arch/x86/xen/xen-ops.h @@ -54,6 +54,7 @@ void xen_teardown_timer(int cpu); cycle_t xen_clocksource_read(void); void xen_setup_cpu_clockevents(void); void __init xen_init_time_ops(void); +void __init xen_init_pad_ops(void); void __init xen_hvm_init_time_ops(void); irqreturn_t xen_debug_interrupt(int irq, void *dev_id); diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index aa31337..c0268c9 100644 --- a/drive...

...if its scheduling parameters --when running under the sedf scheduler-- were not fully specified, making creation fail like in this example here below: 2012-06-16 07:37:47 Z executing ssh ... root@10.80.248.105 xl create /etc/xen/debian.guest.osstest.cfg libxl: error: libxl.c:3619:sched_sedf_domain_set: setting domain sched sedf: Invalid argument libxl: error: libxl_create.c:710:domcreate_bootloader_done: cannot (re-)build domain: -3 Parsing config from /etc/xen/debian.guest.osstest.cfg This is due to the fact the values for period, slice, weight and extratime should be consistent among each oth...

I want to post this but mainly for discussion and early review. It's not safe for these patches to all go upstream yet (because not all filters have been checked/adjusted), but if any patches were to go upstream then probably 1 & 2 only are safe. File, VDDK, memory and data plugins all work, although I have only done minimal testing on them. The current tests, such as they are, all