pure address space feature, so it should be handled there.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34491 a95241bf-73f2-0310-859d-f6bbb57e9c96
and size.
* Made VMArea::Set{Base,Size}() private and made VMAddressSpace a friend.
In vm.cpp the new VMAddressSpace::ResizeArea{Head,Tail}() are used
instead.
Finally all address space changes happen in VMAddressSpace only. *phew*
Now it's ready to be thoroughly butchered. :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34467 a95241bf-73f2-0310-859d-f6bbb57e9c96
This makes it more explicit where the fields are modified.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34464 a95241bf-73f2-0310-859d-f6bbb57e9c96
simplify migration of the area management, but as a side effect, it also
makes area deletion O(1) (instead of O(n), n == number of areas in the
address space).
* Moved more area management functionality from vm.cpp to VMAddressSpace and
VMArea structure creation to VMArea. Made the list and list link members
itself private.
* VMAddressSpace tracks its amount of free space, now. This also replaces
the previous mechanism to do that only for the kernel address space. It
was broken anyway, since delete_area() subtracted the area size instead of
adding it.
* vm_free_unused_boot_loader_range():
- lastEnd could be set to a value < start, which could cause memory
outside of the given range to be unmapped. Haven't checked whether this
could happen in practice -- if so, it would be seriously unhealthy.
- The range between the end of the last area in the range and the end of
the range would never be freed.
- Fixed potential integer overflows when computing addresses.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34459 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the condition variable and synchronization subsystem of the freebsd compat
layer which will be committed next.
* Also there was a discussion about adding these functions on the commit
mailing list. The mail in http://www.freelists.org/post/haiku-commits/r34395-in-haikutrunksrclibscompatfreebsd-network-compatsys,3
is a good sum up of it (need to scroll somewhat down, though).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34458 a95241bf-73f2-0310-859d-f6bbb57e9c96
* "Classified" VMAddressSpace, i.e. turned the vm_address_space_*() functions
into methods, made all attributes (but "areas") private, and added
accessors.
* Also turned the vm.cpp functions vm_area_lookup() and
remove_area_from_address_space() into VMAddressSpace methods. The rest of
the area management functionality will follow soon.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34447 a95241bf-73f2-0310-859d-f6bbb57e9c96
CreateAsmStructOffsetsHeader mechanism to generate a header with macros
defined to the sizes of the structures we're interested in and when compiling
in C mode define the structures as "struct { char bytes[size]; }".
It works in principle, but due to how jam works, one would have to specify the
dependency to the generated header for all sources that include it directly or
indirectly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34441 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use C++ DoublyLinkedList class instead of the struct list.
* Note, this code is untested yet, but I will test it now (Qemu doesn't work
on Haiku anymore for some reason) :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34382 a95241bf-73f2-0310-859d-f6bbb57e9c96
use for the asm_offsets.cpp file, so it can be reused elsewhere.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34311 a95241bf-73f2-0310-859d-f6bbb57e9c96
resource manager.
* Could be drastically improved, though, by taking the fragmentation into
account.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34309 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Implemented renameat(), faccessat(), fchownat(), fchmodat(), and mkfifoat().
* Added stub for mknodat().
* The kernel backend for faccessat() does not yet differentiate between
effective and real user/group IDs, though.
* Removed B_ENABLE_INCOMPLETE_POSIX_AT_SUPPORT, as we now support everything
(more or less). This also closes ticket #4928.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34288 a95241bf-73f2-0310-859d-f6bbb57e9c96
returns the correct error code if the buffer was too small (should be ERANGE
instead of ENOBUF).
* Also, it is now independent of B_PATH_NAME_LENGTH, and therefore should
fulfill POSIX getcwd() requirements. This should also close ticket #3352.
* Is there any reason to allocate another buffer instead of using memmove()
at the end instead of memcpy()?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34276 a95241bf-73f2-0310-859d-f6bbb57e9c96
would always inherit them all, causing quite a number of open files.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34247 a95241bf-73f2-0310-859d-f6bbb57e9c96
checking the physical frame buffer location.
* This allows us to map the whole frame buffer at once, which means there is no
need anymore to remap the memory on mode change.
* Also, this will ease the burden of the MTRRs, as the memory size will be
properly aligned.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34206 a95241bf-73f2-0310-859d-f6bbb57e9c96
all MTRRs at once.
* Added a respective x86_set_mtrrs() kernel function.
* x86 CPU module:
- Implemented the new hook.
- Prefixed most debug output with the CPU index. Otherwise it gets quite
confusing with multiple CPUs.
- generic_init_mtrrs(): No longer clear all MTRRs, if they are already
enabled. This lets us benefit from the BIOS's setup until we install our
own -- otherwise with caching disabled things are *really* slow.
* arch_vm.cpp: Completely rewrote the MTRR handling as the old one was not
only slow (O(2^n)), but also broken (resulting in incorrect setups (e.g.
with cachable ranges larger than requested)), and not working by design for
certain cases (subtractive setups intersecting ranges added later).
Now we maintain an array with the successfully set ranges. When a new range
is added, we recompute the complete MTRR setup as we need to. The new
algorithm analyzing the ranges has linear complexity and also handles range
base addresses with an alignment not matching the range size (e.g. a range
at address 0x1000 with size 0x2000) and joining of adjacent/overlapping
ranges of the same type.
This fixes the slow graphics on my 4 GB machine (though unfortunately the
8 MTRRs aren't enough to fully cover the complete frame buffer (about 35
pixel lines remain uncachable), but that can't be helped without rounding up
the frame buffer size, for which we don't have enough information). It might
also fix#1823.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34197 a95241bf-73f2-0310-859d-f6bbb57e9c96
This is something must must not do in an idle thread or we get the scheduler
into trouble.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34196 a95241bf-73f2-0310-859d-f6bbb57e9c96
to be cloned.
* Added "flags" parameter to the SetTo(const void*,...) version.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34155 a95241bf-73f2-0310-859d-f6bbb57e9c96
to physical memory whose address would accidentally satisfy the
IS_USER_ADDRESS() check.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34136 a95241bf-73f2-0310-859d-f6bbb57e9c96
parameter and request->IsWrite(). The parameter means whether we want to
write to the request's I/O buffer (therefore renamed it to writeToRequest),
while request->IsWrite() indicates whether the request is a write request.
One can only write to a read request's buffer and vice versa.
IOBuffer::LockMemory() also wants to know whether the request is a write
request, not whether we want to write to the memory.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34135 a95241bf-73f2-0310-859d-f6bbb57e9c96
