This usually wasn't a problem as the key buffer is generally large
enough to hold a single value. Still on short buffers or very long
it could have silently overrun before.
This replaces waiting a fixed time of 300ms for the device power to
stabilize. In the ideal case this reduces the boot time by 200ms per
connected device (including internal hubs).
This is very similar to what Linux implements and we use the same time
values. An interval of 25ms is used to check for connection state
changes, the stable time is at least 100ms as per the USB specs and the
whole process times out after 1.5 seconds.
- Sometimes the return type doesn't appear to have a
an associated byte size attribute. If so, simply
revert to using the architecture's register width,
since at least empirically all such cases appear
to be primitive types that fit into one anyways.
- If a node was already expanded, and we then removed/replaced
its children, those wouldn't automatically get their value nodes
added. Consequently, value retrieval for them would fail until
the parent was collapsed/re-expanded. If we encounter such a
model node when receiving a value request, notify the table model so
it can construct the value node appropriately.
- When removing a value node in response to ValueNodeChildrenDeleted,
we need to recurse down and ensure that each node's children are
likewise notified/removed. Otherwise we end up with deleted child
nodes in the node table, which in turn led to potential crashes when
either adjusting a node's type and/or its visible array range.
- Objects that act as ranged containers now expose a menu option
which allows the user to input a comma-separated list of ranges to
show. These need not be contiguous, ergo one can show only
the first and last elements of an array, or some random set of
indices in the middle as well.
Apparently it isn't ready yet. I haven't found a single syslog on Trac
that shows a successful initialization of the driver, and on my
machine, where it does that at least, the system freezes during boot.
* For some reason the code in acpi_processor_init() assumed that the
CPU index returned by ACPI was 1-based. On my machines it is 0-based
and the syslogs on Trac from the last months don't show any
exception. The code even contained a hack to force satisifying that
assumption for a single-CPU machine.
* Instead of calling intel_cpuidle_init()/acpi_cpuidle_init() when
initializing the driver for the device node for CPU 0 -- thus
depending on the order the device manager iterates through the CPU
device nodes -- rather check whether all CPU nodes have indeed been
encountered.
* acpi_cpuidle_init_driver(): Don't leak the cookie in error case.
* acpi_cpuidle_uninit_driver(): Clear the sAcpiProcessor element for
the uninitialized CPU node. We'd also have to unregister the idle
callback when acpi_cpuidle_uninit_driver() is called for the first
CPU device node, but there isn't any API for it ATM.
Fixes a crash on machines with multiple CPUs where acpi_cpuidle_setup()
wouldn't already fail early (apparently only mine).
Casting the difference of the two off_t values to size_t may truncate
the result. Doing so before the comparison will therefore break it.
Instead cast the size to off_t to get around the signed versus unsigned
integer expression comparison and then cast the result of the comparison
to size_t again. Should fix#9714.
This reverts commit f7176b0ee5. Citing Ingo:
"off_t is the correct type to use for addressing pages in a cache/file,
which page_num_t should only be used for physical pages." I'll see how to
fix the GCC 4.7 warnings differently :)
* GCC 4.7 warning: narrowing conversion of '(int)(((ColorPickerView*)this)->ColorPickerView::r * 2.55e+2f)'
from 'int' to 'uint8 {aka unsigned char}' inside { } is ill-formed in C++11 [-Werror=narrowing]
