- Factor out functions for refreshing the repositories and
retrieving the package lists.
- Add a background worker thread which handles those tasks and
then notifies the window when the model is ready.
- Check if we already have a repository cache, and if so, skip the
refresh step, unless forced. The latter will eventually be possible
via the UI.
- Also rework things a bit to fix passing the same reference into the
installed package list repeatedly, thus causing only the first package
to be marked as actually being installed.
- MainWindow now attempts to refresh all available repositories and
fetch their respective package lists on startup. Much still remains
to be done, such as factoring this out into a background process so
it doesn't prevent the window from showing, and making the refresh step
optional if we already have valid repository information, but this at
least gets us showing the available package list from HaikuPorts.
- DecisionProvider and JobStateListener will be needed in order to
interact with the package kit in various ways eventually, though
the implementations are currently all empty.
- Adjust HaikuDepot's PackageManager class to inherit from
BPackageManager, so as to be able to actually interface with
the package repositories.
- If a single thread attempted to establish multiple package kit
contexts, it would fail due to a collision between their respective
temporary directories. As such, use both the thread ID and
system_time() as a random elements in the directory name to ensure
this doesn't occur.
* 'update' takes an existing repository and a package list file and then
creates a new repository from that, avoiding expensive
checksum-recomputations where possible
This is especially important for the assembler code in the kernel,
since it enables workarounds for some critical errata related to
exception handling.
Support for 64-bit atomic operations for ARMv7+ is currently stubbed
out in libroot, but our current targets do not use it anyway.
We now select atomics-as-syscalls automatically based on the ARM
architecture we're building for. The intent is to do away with
most of the board specifics (at the very least on the kernel side)
and just specify the lowest ARMvX version you want to build for.
This will give flexibility in being able to distribute a single
image for a wide range of devices, and building a tuned system
for one specific core type.
Now we check whether the virtual address corresponding to the PTE lies
in an allocated virtual address range. This fixes a cause of #8345:
The assertion would trigger when such an entry was encountered. There
might be other causes that trigger the same assertion, though.
This adds the -mapcs-frame compiler flag for ARM to have "stable"
stack frames, adds support to the kernel for dumping stack crawls,
and initial support for iframes. There' much more functionality
to unlock in KDL, but this makes debugging already a lot more
comfortable.....
- The disassembly dump would consequently stop at the instruction
prior to the actual crash culprit, and also erroneously mark it
as such.
(cherry picked from commit 7de035619b)
Since both platforms can boot the same kernel we must accept either
arg, so we make sure they are identical for now.
TODO: use a union or KMessage maybe?
- Since we actually draw a selection now, change the target address
highlight to clearly distinguish it. Rather than inverting it, it's
now drawn with a normal background and red text in the hex display.
The text mode subcomponent still shows it as an invert though, since
the latter doesn't currently indicate the selection.
- Always grab the address value from the actual register value column,
rather than the one that's in fact under the mouse. Fixes the "Inspect"
item sending you to inspect address 0 if you happened to right click over
the register name rather than the value.
- The offset calculation for mapping the current point wasn't taking
into account the number of bytes per hex block, causing it to be
proportionally further off if one switched to 16/32/64-bit hex mode.
Gets mouse selection working properly in said modes.
This helps when debugging, since when a driver/module causes a crash
while registering with the device manager, you can actually look at
the device manager state ;-)
