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
failed to evaluate, the whole term was ignored. Also, if the left term got
the higher score (and was thus evaluated first), the second term was never
evaluated anymore. This should fix, for example, MDR sometimes not sending
out pending mails.
* Minor cleanup, improved comments.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33496 a95241bf-73f2-0310-859d-f6bbb57e9c96
respective Type classes. StackFrameDebugInfo is pretty much out of work now,
but maybe something comes up later.
* Renamed GlobalTypeLookupContext to GlobalTypeCache and renamed its methods.
* A TeamDebugInfo does now have a GlobalTypeCache which is used for resolving
types. Formerly it was created per stack frame, so all types had to be
resolved after each single step. Single-stepping is usably fast again.
The disadvantage is that DWARF theoretically allows types properties to
depend on instruction/frame/frame base pointer and we don't support that
anymore. I can't think of a reasonable application for that feature, though.
* Refactored DwarfStackFrameDebugInfo:
- Moved the type classes into new DwarfTypes.{h,cpp}.
- Moved the creation of types into new class DwarfTypeFactory.
- Added class DwarfTypeContext which bundles all the dependencies of the type
classes.
* Made DwarfFile a BReferenceable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33495 a95241bf-73f2-0310-859d-f6bbb57e9c96
always return the source string length, we can't really prevent an overflow
of the source address.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33489 a95241bf-73f2-0310-859d-f6bbb57e9c96
