* The GPL license here was a relic from the past to help
control YellowTab's use of Haiku source code. The intent
at the time was to relicense MIT. Some GPL parts remained.
* This is going to get harder and harder to correct over time.
* This code makes Haiku *not* MIT. Lets correct that.
* I reached out to everyone who made changes to these files and
got personal approvals to relicense MIT.
* If I missed somebody, *and* you feel as though the MIT license
doesn't meet your needs, please contact Haiku, Inc. and we will
work to revert your changes.
Marcus Overhagen EMAIL - MIT OK 11/29/17
Stephan Aßmus EMAIL - MIT OK 11/28/17
Axel Dörfler IRC - MIT OK 11/29/17
Ryan Leavengood KEYBASE - MIT OK 11/28/17
Michael Lotz IRC - MIT OK 11/29/17
Adrien Destugues EMAIL - MIT OK 11/28/17
Joachim Seemer EMAIL - MIT OK 11/28/17
Jonas Sundström EMAIL - MIT OK 11/29/17
François Revol IRC - MIT OK 11/29/17
Jérôme Duval EMAIL - MIT OK 11/29/17
Oliver Tappe EMAIL - MIT OK 11/29/17
Dziadek EMAIL - MIT OK 11/29/17
Philippe Saint-Pierre EMAIL - MIT OK 12/6/17
Philippe Houdoin EMAIL - MIT OK 12/8/17
Dario Casalinuovo IRC - MIT OK 12/13/17
Technically a "hack" (but then again most of the config/build stuff is);
as we need to use the system's config/types.h in order to get stdint
definitions and the like.
Previously there was a config_build directory which allowed the existence
of two types.h -- the system one, and the headers/build one, but seeing
as we only need this to provide Haiku-specific core types on other platforms,
using the system's one should be fine.
Our core type definitions have not changed in some time (and it's unclear
when they would change aside from potential new platforms), breakage of the
Haiku-on-Haiku build due to this should not happen often (if ever.)
Since it's just a C compiler "technically" the ABI does not matter,
but since it also can target other ABIs from one toolchain (e.g. x64),
just treat it as GCC4 ABI unilaterally.
Fixes#13847.
Now that we do not target BeOS and also do not include the main headers
directory when building "build" binaries, we can drop the separate
config_build directory and thus also the separate BeBuild.h, and just
..-include the regular one.
The build BeBuild.h defined empty _IMPEXP_ROOT and _IMPEXP_BE preprocessor
macros that the regular one does not; so I also re-synchronized
headers which used these as needed.
We need to handle a case when node size is small reasonably it can be merged with another node or push data from other node to this node.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
We need to handle a case when node is full, the solution should be split or push data to another node.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
CopyOnWrite works like this:
* Cache original node
* Allocating new block
* Cache new block to be writable
* Copy original node to new node, and changing.
Also if a node is already be COW-ed it cannot be COW-ed again, it will be changed in-place instead.
InternalCopy does CopyOnWrite all the nodes that we don't need to change anything on them.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Some details about the current Journal:
* Journal can only end transaction.
* It holds a transaction id of fs (fCurrentGeneration) that increments each time a transaction starts.
* _TransactionWritten now just printing message.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
There are 4 new classes, structs:
* CachedExtent, is a AVLTreeNode, caches the extent locating in extent tree, a extent can be free, allocated, metadata or a data extent. It also hold a references count,
that is incremented each time a new extent refer to it (COW) and item data, that is only for allocated extent (NULL for free).
* CachedTreeExtent, is a AVLTree, cache the whole extent tree and has CachedExtent as its node.
* BlockGroup represents the group of extents that represent the region for each type of allocated extent. For example, region for data extents, metada blocks. It
responsible for inserting nodes in CachedTreeExtent.
* And the final, ExtentAllocator it knows how to allocate/deallocate extents, but for now only the allocating is implemented, actually allocating and deallocating works
are already implemented, they are in functions _AddFreeExtent, _AddAllocatedExtent in CachedTreeExtent. However the deallocating is not needed for now, so it will be
finished later then.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Add BTree::Path as a attribute so enhance performance, so that everytime we iterate through items it wont search all the root to leaf
again. The Iterator is initialized without rewinding to make more flexible.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Remove attribute fCurrentSlot in BTree::Node as it will be handled by Path explicitly. BTree control Path by passing its type in
BTree's method, Path also hold BTree type as its attribute to do some internal actions.
Add constant BTREE_KEY_TYPE_ANY, find search key has this type will success regardless of the found key's type.
Split the the _Find function into Traverse and GetEntry. Traverse will fill in the Path (nodes and slots) along way its finding,
GetEntry will get the item data, item size, key from leaf, if the slot is valid, that we have from Traverse. The _Find function also
check type if is correct and then retrieve. Doing this way there will be more flexible, the "read" flag is not needed as we only
need Path to manipulate tree, and it also enhance the performance at some points, because Path caches all the nodes from root to leaf,
so that we don't have to block_cache_put and block_cache_get after each finding.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
* Not handle traversing type correctly (looks for the graph).
* Reorder the codes because *slot is uninitialized if type is BTREE_EXACT.
* Incorrect return type: int32 -> status_t
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
The glue code pushed 12 bytes to the stack, breaking the 16-byte stack
alignment requirement. This would be fixed by the main() prologue from
gcc, but all "init" and "fini" code (static/global constructors/ destructors)
would run with a misaligned stack.
This was already fixed for x86_64 in hrev49731. Note that the fix here
is slightly different, the pointer is realigned after it is saved to EBP
and the function epilogue restores it from EBP, so no changes to crtn.S are
needed.
This application tests the BMediaTrack/BMediaFile API and underlying
ffmpeg plugin for video decoding. You can press (or hold) any key to go
through frames in a video. This avoids debugging both MediaPlayer and
the underlying libraries at the same time.
It shows that ReadFrames is getting video frames out of PTS order.
I still don't get what's happening, but doing the cookie parsing at the
same time as the main thread is handling HeadersReceived seems to
trigger a memory corruption, and it will escape all my attempts to debug
it (adding printfs or any other slight change to the code will make it
go away). So just chage the order we do things and hope that's enough to
always avoid it.
As a side effect, HeadersReceived can now rely on the cookies being
already stored in the cookie jar, which I think makes more sense.
I still plan to rewrite the HTTP request code as a proper state machine,
instead of one long Run() function. This would allow to run it in
smaller steps, and thus group multiple requests in a single thread
(triggering them from poll, select, or similar).
