search for: cn_msg

...er mode component first registers with the + * the kernel component. Subsequently, the kernel component requests, data + * for the specified keys. In response to this message the user mode component + * fills in the value corresponding to the specified key. We overload the + * sequence field in the cn_msg header to define our KVP message types. + * + * We use this infrastructure for also supporting queries from user mode + * application for state that may be maintained in the KVP kernel component. + * + * XXXKYS: Have a shared header file between the user and kernel (TODO) + */ + +enum kvp_op { + KV...

...er mode component first registers with the + * the kernel component. Subsequently, the kernel component requests, data + * for the specified keys. In response to this message the user mode component + * fills in the value corresponding to the specified key. We overload the + * sequence field in the cn_msg header to define our KVP message types. + * + * We use this infrastructure for also supporting queries from user mode + * application for state that may be maintained in the KVP kernel component. + * + * XXXKYS: Have a shared header file between the user and kernel (TODO) + */ + +enum kvp_op { + KV...

...ode component first registers with the + * the kernel component. Subsequently, the kernel component requests, = data + * for the specified keys. In response to this message the user mode = component + * fills in the value corresponding to the specified key. We overload the + * sequence field in the cn_msg header to define our KVP message types. + * + * We use this infrastructure for also supporting queries from user mode + * application for state that may be maintained in the KVP kernel = component. + * + * XXXKYS: Have a shared header file between the user and kernel (TODO) + */ + +enum kvp_op { +...

...ode component first registers with the + * the kernel component. Subsequently, the kernel component requests, = data + * for the specified keys. In response to this message the user mode = component + * fills in the value corresponding to the specified key. We overload the + * sequence field in the cn_msg header to define our KVP message types. + * + * We use this infrastructure for also supporting queries from user mode + * application for state that may be maintained in the KVP kernel = component. + * + * XXXKYS: Have a shared header file between the user and kernel (TODO) + */ + +enum kvp_op { +...

...er mode component first registers with the + * the kernel component. Subsequently, the kernel component requests, data + * for the specified keys. In response to this message the user mode component + * fills in the value corresponding to the specified key. We overload the + * sequence field in the cn_msg header to define our KVP message types. + * + * We use this infrastructure for also supporting queries from user mode + * application for state that may be maintained in the KVP kernel component. + * + * XXXKYS: Have a shared header file between the user and kernel (TODO) + */ + +enum kvp_op { + KV...

...er mode component first registers with the + * the kernel component. Subsequently, the kernel component requests, data + * for the specified keys. In response to this message the user mode component + * fills in the value corresponding to the specified key. We overload the + * sequence field in the cn_msg header to define our KVP message types. + * + * We use this infrastructure for also supporting queries from user mode + * application for state that may be maintained in the KVP kernel component. + * + * XXXKYS: Have a shared header file between the user and kernel (TODO) + */ + +enum kvp_op { + KV...

...KVP_IDX, CN_KVP_VAL }; +static const char kvp_name[] =3D "kvp_kernel_module"; +static int timeout_fired; + +/* + * Register the kernel component with the user-level daemon. + * As part of this registration, pass the LIC version number. + */ + +static void +kvp_register(void) +{ + + struct cn_msg *msg; + + msg =3D kzalloc(sizeof(*msg) + strlen(HV_DRV_VERSION) + 1 , = GFP_ATOMIC); + + if (msg) { + msg->id.idx =3D CN_KVP_IDX; + msg->id.val =3D CN_KVP_VAL; + msg->seq =3D KVP_REGISTER; + strcpy(msg->data, HV_DRV_VERSION); + msg->len =3D strlen(HV_DRV_VERSION) + 1; + cn_net...

...KVP_IDX, CN_KVP_VAL }; +static const char kvp_name[] =3D "kvp_kernel_module"; +static int timeout_fired; + +/* + * Register the kernel component with the user-level daemon. + * As part of this registration, pass the LIC version number. + */ + +static void +kvp_register(void) +{ + + struct cn_msg *msg; + + msg =3D kzalloc(sizeof(*msg) + strlen(HV_DRV_VERSION) + 1 , = GFP_ATOMIC); + + if (msg) { + msg->id.idx =3D CN_KVP_IDX; + msg->id.val =3D CN_KVP_VAL; + msg->seq =3D KVP_REGISTER; + strcpy(msg->data, HV_DRV_VERSION); + msg->len =3D strlen(HV_DRV_VERSION) + 1; + cn_net...

I am enclosing a patch that implements the KVP (Key Value Pair) functionality for Linux guests on HyperV. This functionality allows Microsoft Management stack to query information from the guest. This functionality is implemented in two parts: (a) A kernel component that communicates with the host and (b) A user level daemon that implements data gathering. The attached patch (kvp.patch) implements

I am enclosing a patch that implements the KVP (Key Value Pair) functionality for Linux guests on HyperV. This functionality allows Microsoft Management stack to query information from the guest. This functionality is implemented in two parts: (a) A kernel component that communicates with the host and (b) A user level daemon that implements data gathering. The attached patch (kvp.patch) implements

...; +static const char kvp_name[] = "kvp_kernel_module"; +static int timeout_fired; +static u8 *recv_buffer; +/* + * Register the kernel component with the user-level daemon. + * As part of this registration, pass the LIC version number. + */ + +static void +kvp_register(void) +{ + + struct cn_msg *msg; + + msg = kzalloc(sizeof(*msg) + strlen(HV_DRV_VERSION) + 1 , GFP_ATOMIC); + + if (msg) { + msg->id.idx = CN_KVP_IDX; + msg->id.val = CN_KVP_VAL; + msg->seq = KVP_REGISTER; + strcpy(msg->data, HV_DRV_VERSION); + msg->len = strlen(HV_DRV_VERSION) + 1; + cn_netlink_send(ms...

...; +static const char kvp_name[] = "kvp_kernel_module"; +static int timeout_fired; +static u8 *recv_buffer; +/* + * Register the kernel component with the user-level daemon. + * As part of this registration, pass the LIC version number. + */ + +static void +kvp_register(void) +{ + + struct cn_msg *msg; + + msg = kzalloc(sizeof(*msg) + strlen(HV_DRV_VERSION) + 1 , GFP_ATOMIC); + + if (msg) { + msg->id.idx = CN_KVP_IDX; + msg->id.val = CN_KVP_VAL; + msg->seq = KVP_REGISTER; + strcpy(msg->data, HV_DRV_VERSION); + msg->len = strlen(HV_DRV_VERSION) + 1; + cn_netlink_send(ms...

An implementation of key/value pair feature (KVP) for Linux on HyperV. In this version of the patch I have addressed all the comments I have received to date. I have also included the code for the user-level daemon here for your reference. Signed-off-by: K. Y. Srinivasan <ksrinivasan at novell.com> -------------- next part -------------- An embedded and charset-unspecified text was

An implementation of key/value pair feature (KVP) for Linux on HyperV. In this version of the patch I have addressed all the comments I have received to date. I have also included the code for the user-level daemon here for your reference. Signed-off-by: K. Y. Srinivasan <ksrinivasan at novell.com> -------------- next part -------------- An embedded and charset-unspecified text was

This patch set removes all un-needed DPRINT and printk calls and replaces the remaining ones with the correct pr_, dev_ and netdev_ calls from hv_vmbus, hv_netvsc, hv_timesource and hv_utils. Several DPRINTS are remaining that will be cleaned up in my next set of patches. They deal with printing out certain debugging that will be implemented slightly differently. The remaining hv_storvsc and

This patch set removes all un-needed DPRINT and printk calls and replaces the remaining ones with the correct pr_, dev_ and netdev_ calls from hv_vmbus, hv_netvsc, hv_timesource and hv_utils. Several DPRINTS are remaining that will be cleaned up in my next set of patches. They deal with printing out certain debugging that will be implemented slightly differently. The remaining hv_storvsc and