* copy the needed jam files during compile time. This ensures the correct data
files are used, for example in non-trunk builds
* -f now only removes the generated at runtime listing of available packages
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37465 a95241bf-73f2-0310-859d-f6bbb57e9c96
vm_page::Init().
* Made vm_page::wired_count private and added accessor methods.
* Added VMCache::fWiredPagesCount (the number of wired pages the cache
contains) and accessor methods.
* Made more use of vm_page::IsMapped().
* vm_copy_on_write_area(): Added vm_page_reservation* parameter that can be
used to request a special handling for wired pages. If given the wired pages
are replaced by copies and the original pages are moved to the upper cache.
* vm_copy_area():
- We don't need to do any wired ranges handling, if the source area is a
B_SHARED_AREA, since we don't touch the area's mappings in this case.
- We no longer wait for wired ranges of the concerned areas to disappear.
Instead we use the new vm_copy_on_write_area() feature and just let it
copy the wired pages. This fixes#6288, an issue introduced with the use
of user mutexes in libroot: When executing multiple concurrent fork()s all
but the first one would wait on the fork mutex, which (being a user mutex)
would wire a page that the vm_copy_area() of the first fork() would wait
for.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37460 a95241bf-73f2-0310-859d-f6bbb57e9c96
Revert r33437, which was missing the root cause.
Spotted by Christophe Huriaux, thanks.
And welcome in contributors list!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37437 a95241bf-73f2-0310-859d-f6bbb57e9c96
unarchiving protocol to support archival of arbitrary object graphs.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37431 a95241bf-73f2-0310-859d-f6bbb57e9c96
to complete it if you find other misses or false positives.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37430 a95241bf-73f2-0310-859d-f6bbb57e9c96
I've removed it for now, until someone finds the time to look into it.
* Therefore, enabled all supported devices for the rtl81xx driver.
* Made the rtl81xx driver actually work by adding the missing PHYs - it doesn't
use the same PHYs as the rtl8139 driver. Imported the rgephy.c|h from FreeBSD
8 (not yet in vendor branch, but unchanged).
* It seems to work reliably with Gigabit now, albeit a bit slow, and with too
high CPU load.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37425 a95241bf-73f2-0310-859d-f6bbb57e9c96
raw file. Sorry, but You'll have to reconfigure your deskar to
accomodate this!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37420 a95241bf-73f2-0310-859d-f6bbb57e9c96
with only a single readable/writable/executable text+data segment.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37415 a95241bf-73f2-0310-859d-f6bbb57e9c96
* FontCacheEntry will not use the "empty" glyph from fonts anymore, so squares are not drawn anymore
* GlyphLayoutEngine will try the VL Gothic font, if the requested font doesn't have any glyph fo the requested character. The
caching for the fallback is suboptimal, and the font choice quite limited, but this allows at least japanese text to display
properly on haiku out of the box.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37413 a95241bf-73f2-0310-859d-f6bbb57e9c96
