link to them.
* VM{Kernel,User}AddressSpace manage the respective VMArea subclass now, and
VMAddressSpace has grown factory methods {Create,Delete}Area.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34493 a95241bf-73f2-0310-859d-f6bbb57e9c96
new derived classes VM{Kernel,User}AddressSpace. Currently those are
identical, but that will change.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34492 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
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
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
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
* Made reference returned by _GetKey() const. That's sufficient.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33898 a95241bf-73f2-0310-859d-f6bbb57e9c96
to the owning team.
* Instead, the team now maintains a list containing the ports it owns.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33771 a95241bf-73f2-0310-859d-f6bbb57e9c96
* This makes sem_delete_owned_sems() a lot more efficient; before it would need
to scan the entire semaphore table.
* This speeds up the test build of the kernel by another 2 seconds (with
KDEBUG=2) on my laptop.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33743 a95241bf-73f2-0310-859d-f6bbb57e9c96
(hopefully) correct place.
* It seems to be even harder to understand basic locking primitives: when you
think about it, it shouldn't surprise you that conditional variables never
return B_WOULD_BLOCK. This fixes gdb again.
* Added tracing support to the ports subsystem.
* get_port_message() will now resize the port heap if needed (but will also
take timeouts into account while doing so, more or less). The initial port
space is 4MB (as before), the growth rate is the same, and the system wide
limit is arbitrarily set to 64 MB (all swappable). A team limit has been set
to 8 MB, but is not enforced yet. Since ports are using up address space in
the kernel, those seems to be proper limits.
* This also fixes a strange, and rare lockup where the mouse cursor would still
move, but everything else would basically hang, but look perfectly normal from
KDL on the first look. As recently happened on Brecht's laptop, and debugged
by mmlr and me: the cbuf space got used up when lots of windows wanted to
redraw after a workspace switch. The app_server wouldn't answer anymore to
client requests, but thought it would have done so, as LinkSender::Flush()
doesn't care if it got a B_NO_MEMORY (the ports will now block until memory
is available if possible, so that should not be a problem anymore).
* Improved "port" KDL command, it now also prints the messages in the port.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33735 a95241bf-73f2-0310-859d-f6bbb57e9c96
* its own heap allocator instead of cbuf - this makes cbuf superfluous, and I
therefore removed it from the kernel. The heap is swappable, so lifts the
kernel's resource usage a bit. In the future, the heap should grow as well;
right now it should be at least as good as before.
* it no longer uses spinlocks, but just mutexes now for better scalability - it
was not usable with interrupts turned off anyway (due to its semaphore usage).
* it no longer uses semaphores, but condition variables.
* Needed to move the port initialization to a later point, as swappable memory
wasn't usable that early.
* All ports test are still passing, hopefully I didn't mess anything up :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33728 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Allow an allocator to be created on the heap to allow for non-locked
allocators to be created.
* Some cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33721 a95241bf-73f2-0310-859d-f6bbb57e9c96
read out in the ConditionVariableEntry::WaitStatus(). That way you can notify
with a specific status that can be read out on the other end.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33718 a95241bf-73f2-0310-859d-f6bbb57e9c96
high contention of the read lock (I experimented with the VM page mapping
lock)), it actually hurt the compile performance pretty obviously.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33647 a95241bf-73f2-0310-859d-f6bbb57e9c96
makes the reader case a lot less expensive, and should relieve the thread
spinlock contention a bit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33643 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
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
