them (which you previously could use to easily crash/take over Haiku).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33570 a95241bf-73f2-0310-859d-f6bbb57e9c96
actual digits. Therefore the buffer was always too small leading to memory
corruption. Use the version that allocates the string for us instead, then trim
it and assign it to the result.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33566 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Tracker forwards auto mounter related messages to the mount_server.
* Rewrote AutoMounterSettings to not know AutoMounter and use
the layout-management.
* Moved the "Eject When Unmounting" setting into the Mount Settings.
* Launch the mount_server during boot, but delay the script until all
previously mounted volumes have been mounted. This solves some annoying
timing bugs during boot. For example when you have desktop backgrounds
on other volumes and some servers don't deal well with the situation
of links to add-ons on other volumes becoming valid with a delay...
* src/kits/tracker/Commands.h includes the private headers/private/
mount/MountServer.h header, which made adjustments to the DiskUsage
Jamfile necessary.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33555 a95241bf-73f2-0310-859d-f6bbb57e9c96
the team with the signature becomes a valid target for BMessages.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33553 a95241bf-73f2-0310-859d-f6bbb57e9c96
and stops processing if it finds something wrong.
* The default indirect/double array size differs from BeOS' BFS. I've changed
the size for double indirect arrays only, since the other size should work
either way (not tested yet, this change has a negative effect on the maximum
file size, but improves BeOS compatibility).
* The read/write path of BFS is now double indirect block size agnostic, and
should work with what it finds.
* Merged all double indirect size computation into some utility inline
functions.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33551 a95241bf-73f2-0310-859d-f6bbb57e9c96
Locker.cpp.
* The services are now using recursive_locks, and rw_locks instead.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33548 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
