This is a leftover from the r25913 build fix. It used to be an out parameter.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38294 a95241bf-73f2-0310-859d-f6bbb57e9c96
This remedies "Current thread pointer [...] is an address we can't read from."
on entering KDL. Closes ticket #6163.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38293 a95241bf-73f2-0310-859d-f6bbb57e9c96
Let setting the memory type to B_MTR_UC succeed.
Add initial support for those memory types in the translation map,
pointed out by Ingo in ticket #5193.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38292 a95241bf-73f2-0310-859d-f6bbb57e9c96
Revert r36886 and fix compilation of insert_virtual_range_to_keep().
The use of void* vs. addr_t matches the surrounding boot loader code
but should probably be revised in favour of addr_t.
create_area() in the kernel wrongly assumed a RAM-backed address range,
which was destined to fail since ranges below the kernel address space
were ignored anyway. Use vm_map_physical_memory() instead.
This fixes a hang once the frame buffer and other resources used by OF
get unmapped. Closes ticket #5193 again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38291 a95241bf-73f2-0310-859d-f6bbb57e9c96
There are TODO's in here, because the ACPI module needs restructuring and which I will take care of.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38289 a95241bf-73f2-0310-859d-f6bbb57e9c96
It unloads any media_format mappings when an add-on
becomes unavailable, and consequently reloads the
supported formats and similar when the same add-on
becomes available again. Previously it would only
load previously unkown add-ons by node-monitor
events (unkown name). What also works is that user
add-ons shadow/hide system add-ons when installed,
and the system add-on will become effective immediately
when removing the user add-on again. One thing to
note is that certain IDs will not stay consistent.
I am not aware of an application for which it could
be a problem, most should rememeber codecs by name.
In any case, I only tested add-on events a lot, and
not so much the effects of unstable media_file_format
IDs, so it's possible there are regressions, though
only when installing new versions of add-ons, which
previously mostly required a media_server restart
anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38282 a95241bf-73f2-0310-859d-f6bbb57e9c96
everything more readible.
* Once I understood better how everthing is supposed
to work, I've fixed some bugs.
* The most important problem was that AddDirectory()
placed the wrong entry (resolved symlinks) into the
entry list it keeps for each directory. This resulted
in the mechanisms not working at all when an add-on
was a symlink.
* There was a hidden TODO, which would mean that moving
an add-on from one watched directory into another,
like from home/config/add-ons/... into common/add-ons/...
would drop the client application (media_server,
input_server, ...) into the debugger.
* The fFormerEntries list did not seem to serve any
purpose. Basically it would not disable add-ons
removed from a watched directory unless it changed
it's name at the same time. I've removed it completely,
since it didn't seem to be an optimization
(entry cache) either.
* Each actual add-on file is now node-monitored for
stat changes. So if you have a link in the add-on
folder, and the linked to add-on changes, it triggers
a reload of the add-on now. This will make it much
more pleasant to develop add-ons and have them affective
immediately.
I tested with a fresh image, but there are no immediate
regressions I am aware of. I could imagine that messing
with certain add-ons can have a bad effect now, like
removing the keyboard input_server add-on may trigger the
keyboard to stop working immediately without an input_server
restart, but Tracker should warn before it happens.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38280 a95241bf-73f2-0310-859d-f6bbb57e9c96
problem (since + binds stronger than >>)
Stephan: please review, esp since I don't know how to test this!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38279 a95241bf-73f2-0310-859d-f6bbb57e9c96
Stephan: please yell if you dislike the formatting of the large expressions now
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38278 a95241bf-73f2-0310-859d-f6bbb57e9c96
* no need to overload ScrollTo() with a non-related method - renamed local
ScrollTo() to ScrollToBlock()
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38268 a95241bf-73f2-0310-859d-f6bbb57e9c96
* make BDADDR_* macros refer to value types instead of addresses
* adjust all interfaces using bdaddr_t* to use (mostly const) refs instead,
which IMHO makes the interface & code clearer
* that got rid of a couple of const incorrectness casts
* some cleanup along the way
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38265 a95241bf-73f2-0310-859d-f6bbb57e9c96
Fix some more #pragma export warnings treated as errors on ppc.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38258 a95241bf-73f2-0310-859d-f6bbb57e9c96
PowerPC was special-cased to not include posix/regex.h but a local copy.
This caused a warning for undefining __STDC__ and a pointer signedness error.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38257 a95241bf-73f2-0310-859d-f6bbb57e9c96
#pragma export on
and
#pragma export off
result in warnings on ppc, which are now treated as errors.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38256 a95241bf-73f2-0310-859d-f6bbb57e9c96
As an interim solution for fixing the build,
download an ICU package from Haiku Ports.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38254 a95241bf-73f2-0310-859d-f6bbb57e9c96
Coverity was complaining because we did a half-ass check against NULL only to
pass that NULL pointer on to a function that deref'd it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38248 a95241bf-73f2-0310-859d-f6bbb57e9c96
* BBitmap could leak fWindow in operator=()
* two copy constructors didn't initialize the members properly, which
could cause crashes in _CleanUp()
* minor cleanup
Actually found this while staring at CID 254-257, which were false alarm, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38246 a95241bf-73f2-0310-859d-f6bbb57e9c96
really should get rid of the current mail kit some day.
* Fixed another memory leak I stumpled upon.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38245 a95241bf-73f2-0310-859d-f6bbb57e9c96
