OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA.

It now lives in OS.h. The idea is that this will now be
accessible to userland applications, so userland memory
is protected from access by other processes, just as
kernel memory is.

No functional change (the constants are still the same,
though I've changed some to use shifts to make clear
which bits are allocated are which are unused.)

BytePointer: address Axel's post-merge comments

These changes had been on review on Gerrit for a few weeks, why do the
comment come only after they were merged?

Change-Id: I54064973e08b8b4dc0624f4c09c7cafb7f04e437
Reviewed-on: https://review.haiku-os.org/c/1185
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

MessagingService: use BytePointer

Change-Id: If7890e215180206010a374b8afa9f4cd47325afc
Reviewed-on: https://review.haiku-os.org/c/1099
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

Fix GCC 5 maybe-uninitialized warnings.

Signed-off-by: Adrien Destugues <pulkomandy@pulkomandy.tk>

Fixes #12020

* Reverted r33547, this closes bug #4782 - this is obviously a regression in
GCC4.
* Adapted code accordingly.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33592 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Got rid of the duplicated functionalities provided by RWLocker.cpp, and
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

Remove invalid TODO.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29504 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fix two more problems in the messaging service:

1) When searching the area for a place to allocate the next command, the case of the first command being the same as the last command (as is the case after adding the first message) was not correctly considered. This prevented a given area from ever containing more than one command.
2) The size of a command was incorrectly word-aligned. Rather than aligning to 32-bit boundaries, the size was truncated to between 1-3 bytes, leading to command corruption once multiple messages were in the area, eventually causing registrar to crash while retrieving the messages.

Combined these two changes result in us no longer constantly allocating/destroying areas during heavy node monitor activity.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29417 a95241bf-73f2-0310-859d-f6bbb57e9c96

Add a TODO note.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29412 a95241bf-73f2-0310-859d-f6bbb57e9c96

The loop that looks for the next area to add a message to has a somewhat fatal flaw: it checks for a non-zero area size (which is always set to the physical size of the area rather than the number of message commands stored within it). As a consequence, areas would never get cleaned up once allocated, which lead the kernel to steadily bleed memory if any reasonable level of node monitoring activity was going on. We now check whether or not the area's command count is non-zero instead, and use that as the criteria for selection. Fixes ticket #3518.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29411 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Removed -Wno-unused from all KernelMergeObjects in kernel Jamfiles.
* Fixed most of the warnings resulting from that by removing actually not used
variables or moving declaration into the #IF. Left unused functions there
though, as I wouldn't know if they are supposed to be used again.
* Fixed two statements with no effect (clamping to MAX_ANCILLARY_DATA_LEN in
socket.cpp and unsetting fCounterSem in MessagingService.cpp).
* Some style cleanups.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26253 a95241bf-73f2-0310-859d-f6bbb57e9c96

Reordered the functions (private -> public). No functional change.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25637 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed system/core to system/kernel.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12360 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Reverted r33547, this closes bug #4782 - this is obviously a regression in
GCC4.
* Adapted code accordingly.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33592 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Got rid of the duplicated functionalities provided by RWLocker.cpp, and
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

Remove invalid TODO.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29504 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fix two more problems in the messaging service:

1) When searching the area for a place to allocate the next command, the case of the first command being the same as the last command (as is the case after adding the first message) was not correctly considered. This prevented a given area from ever containing more than one command.
2) The size of a command was incorrectly word-aligned. Rather than aligning to 32-bit boundaries, the size was truncated to between 1-3 bytes, leading to command corruption once multiple messages were in the area, eventually causing registrar to crash while retrieving the messages.

Combined these two changes result in us no longer constantly allocating/destroying areas during heavy node monitor activity.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29417 a95241bf-73f2-0310-859d-f6bbb57e9c96

Add a TODO note.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29412 a95241bf-73f2-0310-859d-f6bbb57e9c96

The loop that looks for the next area to add a message to has a somewhat fatal flaw: it checks for a non-zero area size (which is always set to the physical size of the area rather than the number of message commands stored within it). As a consequence, areas would never get cleaned up once allocated, which lead the kernel to steadily bleed memory if any reasonable level of node monitoring activity was going on. We now check whether or not the area's command count is non-zero instead, and use that as the criteria for selection. Fixes ticket #3518.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29411 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Removed -Wno-unused from all KernelMergeObjects in kernel Jamfiles.
* Fixed most of the warnings resulting from that by removing actually not used
variables or moving declaration into the #IF. Left unused functions there
though, as I wouldn't know if they are supposed to be used again.
* Fixed two statements with no effect (clamping to MAX_ANCILLARY_DATA_LEN in
socket.cpp and unsetting fCounterSem in MessagingService.cpp).
* Some style cleanups.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26253 a95241bf-73f2-0310-859d-f6bbb57e9c96

Reordered the functions (private -> public). No functional change.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25637 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed system/core to system/kernel.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12360 a95241bf-73f2-0310-859d-f6bbb57e9c96