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 <ron@debian.org>  Wed, 23 Dec 2015 00:38:47 +1030

bit-babbler (0.4) unstable; urgency=medium

  * Switch to using libusb-1.0 now.  It turns out that libusb-0.1 doesn't
    actually work on kFreeBSD, it only builds there ...  which isn't very
    helpful.  The kFreeBSD port actually uses FreeBSD's own libusb which also
    provides a compatibility API for libusb-1.0 - and we need to jump through
    a few small extra hoops to use it, but it has the advantage of actually
    working, which is a plus.  This also means we immediately get much better
    support and lots of bugfixes for non-Debian platforms too, so this should
    work everywhere that current releases of libusb do now.

  * Drop libftdi.  This is partly a consequence of the above, since a version
    of it built with libusb-1.0 isn't widely available, and partly a result of
    realising we weren't really using anything from it that we couldn't just
    do more easily and more directly though libusb ourselves anyway.  Our code
    ended up being significantly refactored and simplified as a result of this
    and it opened the way for a number of additional easy improvements too.

  * Drop the --device-num option for selecting devices.  Having an arbitrary
    enumeration isn't really all that useful in hotplug environments, and the
    --device-id option now transparently supports selecting devices by their
    serial number, or by either their logical or physical address on the bus,
    so the duplication there was only becoming a source of confusion.

  * More speed and efficiency tuning.  As a result of now having more direct
    control over the device we've been able to notably reduce some of the
    overheads of streaming data out of it, which means we're now using less
    CPU cycles with an increase in throughput for the same device clock rate.

  * Make the libudev build dependency conditional on linux-any so the kFreeBSD
    buildds will actually want to build it.  We can't do much for Hurd until
    someone actually ports libusb-1.0 to it.

  * Make the use of signals which may not exist on all platforms conditional,
    which should enable this to build on MIPS, Sparc, and Alpha too.

 -- Ron Lee <ron@debian.org>  Sat, 05 Dec 2015 04:40:11 +1030

bit-babbler (0.3) unstable; urgency=medium

  * Include a simple example script for reading from the UDP socket.
  * Include the documentation for configuring virtual machine pass-through
    in the binary package as well.
  * Document how to deal with cgroups mandatory access control when using
    devices inside libvirt managed virtual machines.
  * Initial upload to Debian, Closes: #805979

 -- Ron Lee <ron@debian.org>  Tue, 24 Nov 2015 23:15:24 +1030

bit-babbler (0.2) unstable; urgency=low

  * Add the option to read entropy directly from a UDP socket too.
  * Permit TCP to be used for the control socket.  Not all platforms have
    unix domain sockets, and some people might actually want to be able to
    access it remotely anyway.
  * Guard the Linux specific code (for feeding the kernel entropy) to only
    build on Linux, and get it to build with the mingw-w64 cross compiler.
  * Add a system group bit-babbler, and a udev rule which grants permission
    to access the device(s) to people in that group.  This is mostly useful
    for people who want to stream bits directly out of the devices and don't
    need or want the privilege required to be able to write entropy directly
    to the kernel pool.

 -- Ron Lee <ron@debian.org>  Sat, 27 Jun 2015 01:17:17 +0930

bit-babbler (0.1) unstable; urgency=low

  * Initial release

 -- Ron Lee <ron@debian.org>  Tue, 24 Feb 2015 09:23:18 +1030

