search for: info_len

I don't understand how the info_len element from the hid_info_t structure is used in usbhid-ups. It appears to me that the only use of this element is now to indicate the length of the string: > float info_len; /* if ST_FLAG_STRING: length of the string */ The above is clear, if the element is flagged as a string, the size of th...

...uint32_t align, return 0; } -static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw) +static int virtio_ccw_handle_set_vq(SubchDev *sch, CCW1 ccw, bool check_len, + bool is_legacy) { int ret; VqInfoBlock info; + VqInfoBlockLegacy linfo; + size_t info_len = is_legacy ? sizeof(linfo) : sizeof(info); + + if (check_len) { + if (ccw.count != info_len) { + return -EINVAL; + } + } else if (ccw.count < info_len) { + /* Can't execute command. */ + return -EINVAL; + } + if (!ccw.cda) { + return...

...uint32_t align, return 0; } -static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw) +static int virtio_ccw_handle_set_vq(SubchDev *sch, CCW1 ccw, bool check_len, + bool is_legacy) { int ret; VqInfoBlock info; + VqInfoBlockLegacy linfo; + size_t info_len = is_legacy ? sizeof(linfo) : sizeof(info); + + if (check_len) { + if (ccw.count != info_len) { + return -EINVAL; + } + } else if (ccw.count < info_len) { + /* Can't execute command. */ + return -EINVAL; + } + if (!ccw.cda) { + return...

...stponed = 0; + auth_log(authctxt, 0, "gssapi", " ssh2"); dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_TOKEN, NULL); userauth_reply(authctxt, 0); } @@ -563,6 +584,8 @@ OM_uint32 maj_status, min_status; int authenticated; gss_buffer_desc gssbuf,msg_tok; + char *info; + int info_len; if (authctxt == NULL || authctxt->methoddata == NULL) fatal("No authentication or GSSAPI context"); @@ -598,8 +621,24 @@ packet_write_wait(); } - auth_log(authctxt, authenticated, "gssapi", " ssh2"); + switch (gssapi_client_type) { +#if...

..., + { 3, "done and error" }, + { 4, "aborted" }, + { 5, "in progress" }, + { 6, "no test initiated" }, + { 0, "NULL" } +}; + + +/* HUAWEI Snmp2NUT lookup table */ +static snmp_info_t huawei_mib[] = { + + /* Data format: + * { info_type, info_flags, info_len, OID, dfl, flags, oid2info, setvar }, + * + * info_type: NUT INFO_ or CMD_ element name + * info_flags: flags to set in addinfo + * info_len: length of strings if STR + * cmd value if CMD, multiplier otherwise + * OID: SNMP OID or NULL + * dfl: default value + * flags: snmp-ups internal...

Hi all! I'm wondering if there's anyone doing any hacking on the snmp-ups driver at the moment. I've started looking at implementing 3phase-support, and this uncovered some rather unpleasant stuff in the snmp-ups driver that I really need to fix in order to get things sane. Those of you that's allergic to SNMP might want to stop reading now, this is rather icky ;)

Hi, here's the next version of my virtio-1 qemu patchset. Using virtio-1 virtio-blk and virtio-net devices with a guest kernel built from <1416829787-14252-1-git-send-email-mst at redhat.com> still seems to work for the virtio-ccw transport. Changes from v1: - rebased against current master - don't advertise VERSION_1 for all devices, make devices switch it on individually

Hi, here's the next version of my virtio-1 qemu patchset. Using virtio-1 virtio-blk and virtio-net devices with a guest kernel built from <1416829787-14252-1-git-send-email-mst at redhat.com> still seems to work for the virtio-ccw transport. Changes from v1: - rebased against current master - don't advertise VERSION_1 for all devices, make devices switch it on individually

Next version of virtio-1 patches for qemu. Only change from v2 is splitting out the vring accessors into a separate header file - should hopefully fix the build issues. Cornelia Huck (9): virtio: cull virtio_bus_set_vdev_features virtio: support more feature bits s390x/virtio-ccw: fix check for WRITE_FEAT virtio: introduce legacy virtio devices virtio: allow virtio-1 queue layout

Next version of virtio-1 patches for qemu. Only change from v2 is splitting out the vring accessors into a separate header file - should hopefully fix the build issues. Cornelia Huck (9): virtio: cull virtio_bus_set_vdev_features virtio: support more feature bits s390x/virtio-ccw: fix check for WRITE_FEAT virtio: introduce legacy virtio devices virtio: allow virtio-1 queue layout

Yet another version of the virtio-1 support patches. This one has seen some (very) light testing with the virtio-1 guest support patches currently on vhost-next. Changes from v3: - Add support for FEATURES_OK. We refuse to set features after the driver has set this in the status field, and we allow to fail setting the status if the features are inconsistent. - Add missing virtio-1 changes

Yet another version of the virtio-1 support patches. This one has seen some (very) light testing with the virtio-1 guest support patches currently on vhost-next. Changes from v3: - Add support for FEATURES_OK. We refuse to set features after the driver has set this in the status field, and we allow to fail setting the status if the features are inconsistent. - Add missing virtio-1 changes

This patchset aims to get us some way to implement virtio-1 compliant and transitional devices in qemu. Branch available at git://github.com/cohuck/qemu virtio-1 I've mainly focused on: - endianness handling - extended feature bits - virtio-ccw new/changed commands Thanks go to Thomas for some preliminary work in this area. I've been able to start guests both with and without the

This patchset aims to get us some way to implement virtio-1 compliant and transitional devices in qemu. Branch available at git://github.com/cohuck/qemu virtio-1 I've mainly focused on: - endianness handling - extended feature bits - virtio-ccw new/changed commands Thanks go to Thomas for some preliminary work in this area. I've been able to start guests both with and without the

Another iteration of virtio-1 patches for qemu, as always available on git://github.com/cohuck/qemu virtio-1 This one seems to work together with the current vhost-next patches (well, I can ping :) Changes from v4: - add helpers for feature bit manipulation and checking - use 64 bit feature bits instead of 32 bit arrays - infrastructure to allow devices to offer different sets of feature bits

Another iteration of virtio-1 patches for qemu, as always available on git://github.com/cohuck/qemu virtio-1 This one seems to work together with the current vhost-next patches (well, I can ping :) Changes from v4: - add helpers for feature bit manipulation and checking - use 64 bit feature bits instead of 32 bit arrays - infrastructure to allow devices to offer different sets of feature bits

And yet another iteration of virtio-1 support in qemu, tested with the latest virtio kernel patches. Find it at git://github.com/cohuck/qemu virtio-1 Changes from v5: - fixed stupid bug in "virtio: support more feature bits": we need to define a proper prop backend for 64 bit wide handling... - don't negotiate revision 1 unless VERSION_1 is offered - use 64 bit wide features

And yet another iteration of virtio-1 support in qemu, tested with the latest virtio kernel patches. Find it at git://github.com/cohuck/qemu virtio-1 Changes from v5: - fixed stupid bug in "virtio: support more feature bits": we need to define a proper prop backend for 64 bit wide handling... - don't negotiate revision 1 unless VERSION_1 is offered - use 64 bit wide features