Publishing details

Changelog

bit-babbler (0.5) unstable; urgency=medium

  * Add more options to optimise for minimal power consumption.  The defaults
    before now were mostly focussed on keeping a good supply of fresh entropy
    being regularly mixed into the kernel pool, and on minimising the risk of
    starvation delays when demand is high.  But there's an equally important
    group of users who not only want good entropy, but also want to minimise
    idle power usage as much as possible.  So we now have some extra tunables
    to better support that too.

    The rate at which new entropy is mixed into the kernel pool even when it
    has not fallen below its low water mark is now directly configurable, as
    is the rate at which we throttle down requesting more entropy from the
    hardware when real demand for it falls.  Tuning these can minimise how
    often we are responsible for waking the CPU on an otherwise idle system.

    It is also now possible to configure the devices to be released when we
    expect to be idle beyond a given period of time, which will allow them to
    be powered down and suspended, and only woken again when we do need more
    entropy from them.  There are new udev rules which automatically enable
    the USB autosuspend feature of the Linux kernel for them when they are
    plugged in, which means this will work without needing to manually set
    all that up (unless you want to further tweak the parameters there too).

  * Don't create the control socket by default when only a limited number of
    output --bytes are requested.  It can still be enabled explicitly if you
    do want it available while they are being read, but that's normally of
    fairly limited use, and it's otherwise just annoying to have to remember
    to explicitly disable it when extracting a block of entropy in this way,
    and confusing to users if it complains they don't have permission to
    (re)create it in the default location.

  * Defer device initialisation until the pool threads have been started.
    Most users won't really notice any difference from that, but when you
    have 100 devices in a machine together then even small delays quickly
    add up to become a thumb twiddling pause if they are serialised rather
    than being run in parallel.

  * Better support for pass-through to libvirt managed virtual machines when
    there is more than one BitBabbler device in the host.

    This is still more painful than it really ought to be, but we now have a
    big enough hammer pounding on enough of the rough edges in libvirt support
    for things to work like USB devices should be expected to work.  They can
    be hotplugged dynamically without admin intervention to the guest machines
    you want them assigned to, and assigned to guest machines without fragile
    hacks based on which USB port they are plugged into.

 -- Ron Lee <email address hidden>  Wed, 23 Dec 2015 00:38:47 +1030

Available diffs

Builds

Built packages

Package files