these interfaces are now available.
* Don't be quite so paranoid by default, the checks that are on by default
should be enough to detect most memory corruptions.
This makes the debug heap way more usable, so much that you can even use it as
your normal everyday heap without noticing much performance impact (it has quite
a bit of additional memory overhead though).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33544 a95241bf-73f2-0310-859d-f6bbb57e9c96
libroot. The mutex is a simple benaphore, the rw_lock is pretty much the same
as the one from libkernelland_emu but uses a mutex per lock instead of emulating
a global thread lock. Also added MutexLocking and RWLock{Read|Write}Locking and
AutoLockers based on them. It's cased with __cplusplus so the locks are also
usable from C. Everything's currently exposed in shared/private/locks.h but I
think we should make these locking primitves public.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33543 a95241bf-73f2-0310-859d-f6bbb57e9c96
indices we store in the fields of subsequent BRows. Fixes the broken threads
list in Debugger (should be some ticket -- can't access Trac ATM).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33539 a95241bf-73f2-0310-859d-f6bbb57e9c96
info would decide which one to start. Now, this is only the last comparison
taken into account: first, the search path will be checked, then, any apps
in the /system folder are selected. Only after that, the version check will
be performed.
* This should improve the choices made, especially when you have a second set
of binaries around due to having built Haiku.
* This therefore also fixes that Haiku would wait for the wrong input_server on
shutdown, as the registrar didn't (and rightly so) recognize the input_server
as a system app since the wrong one had been started.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33528 a95241bf-73f2-0310-859d-f6bbb57e9c96
in the free and/or clear queue. This performs better in the case where only few
pages are free/clear but performs worse in the case where there are a lot of
usable pages. It's not used anywhere but it might come in handy one time.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33527 a95241bf-73f2-0310-859d-f6bbb57e9c96
PageWriteTransfer. This makes the transfer accept virtually contiguous pages,
where the offset is contiguous on either end of the current transfer, but where
the pages aren't physically contiguous. It will then add seperate iovecs for
these pages (32 at max right now). This reduces the number of IO requests
generated and allows for optimizations down the IO path (like in the physical to
virtual mapping case for example).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33526 a95241bf-73f2-0310-859d-f6bbb57e9c96
need for the IO -> InternalIO indirection as it is always fed virtual buffers,
which simplifies things a bit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33525 a95241bf-73f2-0310-859d-f6bbb57e9c96
is virtual already it just returns the vecs directly, if it is physical it takes
over the task of virtualizing the vecs either using vm_map_physical_memory_vecs,
if there are multiple vecs or more than one page, or falls back to page wise
mapping if mapping fails or is not needed. In the best case, scattered physical
pages are mapped into one linear virtual buffer so that subsystems operating on
virtual memory only get a single vector and can then burst read/write.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33524 a95241bf-73f2-0310-859d-f6bbb57e9c96
takes a list of iovecs describing the physical pages to be mapped. With it one
can map a set of physically disjoint pages into one linear virtual range. This
is a private API right now, but we might want to make it public as
map_physical_memory_vecs alongside map_physical_memory.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33523 a95241bf-73f2-0310-859d-f6bbb57e9c96
contiguous. Was used to optimized CD boot before the alpha release.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33521 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Note while this fixed running BeOS apps using BJoystick, it breaks all apps
(and SDL) that have been compiled for Haiku R1/alpha1. It's really bad that
r27171 went through unnoticed. We should really try harder next time (and
try to get the ABI change detection script working in an automated way).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33520 a95241bf-73f2-0310-859d-f6bbb57e9c96
frame changes. Currently that's only the expanded/collapsed state of the
items in the tree view, but that already makes single stepping through code
much less annoying.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33512 a95241bf-73f2-0310-859d-f6bbb57e9c96
* IsNodeExpanded(): It always returned false due to a missing return.
* _SetNodeExpanded(): We must call our version of ExpandOrCollapse() or the
listeners won't be notified.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33508 a95241bf-73f2-0310-859d-f6bbb57e9c96
are required to be physically contiguos, which should be reworked to put them
into seperate iovecs. Still this manages to combine a great deal of page
writes into larger bursts already. Reduces the amount of IO requests being
scheduled (and greatly benefits media where page wise writes are slow when
they are accessed through a non-IOScheduler path, i.e. USB mass storage until
that is properly implemented).
* Abstracted per page page writing tasks into a PageWriteWrapper class.
* Abstracted per transfer page writing tasks into PageWriteTransfer class which
formerly was the PageWriterCallback.
* Use both classes from the PageWriterRun and from
vm_page_write_modified_page_range to remove code duplication.
* Adjusted synchronous VMAnonymousCache::Write() to cope correctly with larger
iovecs and more than one iovec. It assumed that there was exactly one page per
vector previously.
* Introduced MaxPagesPerWrite() and MaxPagesPerAsyncWrite() to VMCache to allow
a cache to specify restricitions. VMAnonymousCache does restrict the max pages
to 1 for WriteAsync right now as I didn't feel like reworking that one to cope
with non single page writes just yet.
* Pulled out PageWriteTransfer methods for better readability.
* Some typo fixes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33507 a95241bf-73f2-0310-859d-f6bbb57e9c96
reads or writes for old style drivers, map the physical memory at once. Since
USB is pretty much the only one affected and there small reads/writes are
exponentially slower, the performance gain of the burst transfer far outweighs
the additional overhead of the mapping. Still this could be further optimized
and will eventually be superseeded by also providing a physical memory API in
USB. For now it should bring back USB reads to an acceptable level. Writes are
still page wise though because of how writing back memory works in general.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33503 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Fixed issues sending data over USB bus (actually write data when
requested to; increased timeout when writing data).
- Added usb_printer to build and Haiku image.
- Sending data to printer over USB bus works now in Haiku (cat ... >
/dev/priner/usb/0). Not sure if it works when printing from an
application as I don't have a driver that supports my printer yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33501 a95241bf-73f2-0310-859d-f6bbb57e9c96
printer drivers expect the existence of this folder (for instance
Philippes Canon bubblejet driver).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33500 a95241bf-73f2-0310-859d-f6bbb57e9c96
--Cette ligne, et les suivantes ci-dessous, seront ignorées--
A src/preferences/fonts/fi.catkeys
M src/preferences/fonts/Jamfile
A src/preferences/appearance/fi.catkeys
M src/preferences/appearance/Jamfile
A src/preferences/locale/fi.catkeys
M src/preferences/locale/Jamfile
A src/preferences/bluetooth/fi.catkeys
M src/preferences/bluetooth/Jamfile
A src/preferences/cpufrequency/fi.catkeys
M src/preferences/cpufrequency/Jamfile
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33497 a95241bf-73f2-0310-859d-f6bbb57e9c96
