When forking a team, copy on write areas (and therefore caches) are
created for all the areas in the parent team, but they were always
created as swappable. If the parent team had some B_FULL_LOCK areas,
which aren't swappable, the wrong type of cache would be created which
lead to them not being mergeable later on (causing a panic).
Comments about a possibly cleaner way to figure out the cache type
would be welcome.
* Define a MEMALIGN macro that is either just defined to malloc() or
to the actual memalign() depending on where KMessage is used. We only
use memalign() inside the kernel and libroot.
* Add a comment to the macro explaining that this allows the use of
special heap implementations that might return unaligned buffers for
debugging purposes.
- If multiple nested namespaces were involved in a name,
GetFullyQualifiedDIEName() would erroneously wipe out each one
as it walked up, leaving you with only the top level namespace.
- Don't touch the output parameter unless we're certain we succeeded.
- Use the artificial attribute to more intelligently determine when to omit
parameters. Fixes the first parameter on static class functions being
skipped incorrectly.
- Correctly handle varargs functions.
* Yet more nice way to fix Coverity issues fixed by hrev43460.
Thanks Rene Gollent for pointing it out!
* Potential Coverity issues fixed for sis19x driver too.
The change in hrev43405 wasn't correct, as it put the reference
object definition after the one of the corresponding locker, causing
the reference to be released before the unlock would happen.
Finally fixes #8187. Thanks Ingo for pointing that out.
* The call to _TeamDied() causes the team that the iterator points to
be removed from the map. Therefore the iterator becomes invalid and
may not be accessed anymore (including incrementing it). As we've had
to unlock, anything might have happened to to map, so take the safe
route and just start over.
* For each dead team that was found the AppManager was unlocked, but
there were no balancing lock calls, therefore causing the lock count
to get corrupted.
While this isn't really correct, it works for the use case it is
intended and doesn't open the can of worms we get when trying to do
memalign() across platforms (due to build tools use of KMessage).
* If we cloned the buffer due to misalignment, only free the old buffer
if we actually own it (i.e. if it was allocated by us).
* Set the KMESSAGE_OWNS_BUFFER flag after cloning the buffer. Previously
the buffer was leaked in the clone case.
* If there is an alignment requirement then better use memalign() to
make sure that it is met.
* Since the BMessageAdapter possibly sets a buffer directly, make a
properly aligned copy of the buffer if it happens to be misaligned.
* Not including malloc.h caused the memalign() signature to not be a C
signature, therefore leading to linking errors. Fix the missing
include and explicitly add extern "C" as well.
* Some remaining asterisk style cleanup.
* This document was written during GCI 2011
by Peter Poláčik and is explaining how to use
makefile and Jamfile engines to start and
setup new development projects for Haiku.
Signed-off-by: Siarzhuk Zharski <zharik@gmx.li>
At least as far as I can tell, the template parameters are actually exported
as part of the DIESubprogram name itself, and don't need to be separately
retrieved.
* add DPBridge encoder flag and set during connector detection
* if external bridge found, do external DDC setup
* pass connectorIndex vs displayIndex to encoder_*_setup
* some of the DP AUX channel stuff should go into accelerant
common code some day like i2c.
* remove posix return
* pass GPIO hwLine through vs connector index
* variable scope cleanup
* make lowest level dp aux AtomBIOS call static, non-public
as it is always called by connector code
When retrieving modifiers, we're actually pulling them off the type
in reverse order. Consequently we need to build the type's modifier string
similarly.
If the first modifier is a const, prepend it to type name instead.
The fModes array is realloc'ed as needed when adding modes. Therefore
the fModes pointer handed in to AddModes() becomes invalid once
_MakeSpace() returns in that function causing a freed memory block to
be used as input.
To avoid that we make a copy of the base mode list and then use that to
add the modes for each color space.
The file content isn't normally 0 terminated, so making a string out of
it would usually result in reading beyond the allocated buffer to find
the string length, possibly leading to a crash.
* clean up previously changed error returns in 8c01b4. For
some reason I thought B_ERROR was the only non-positive
status.
* add VESA DisplayPort defines. Only a subset so it's local
to radeon_hd for now.
* this completes basic AUX transaction code, still untested
