-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pkg/tlsf: revert to original api #9006
Conversation
{ | ||
(void)user; | ||
- printf("\t%p %s size: %x (%p)\n", ptr, used ? "used" : "free", (unsigned int)size, block_from_ptr(ptr)); | ||
+ printf("\t%p %s size: %x (%p)\n", ptr, used ? "used" : "free", (unsigned int)size, (void *)block_from_ptr(ptr)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this small fix is something we should try to get upstream.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, I'll try to do that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done: mattconte/tlsf#5
Travis is failing in the CPP check for a line number I didn't modify. |
examples/ccn-lite-relay/Makefile
Outdated
|
||
USEPKG += tlsf |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could model tlsf
as a dependency for tlsf-malloc
. Using tlsf-malloc
without tlsf
doesn't make much sense, or am I missing something? This way, we could skip the explicit USEPKG += tlsf
statement.
--
Just saw that you wrote USEPKG += tlsf
in pkg/tlsf/contrib/Makefile.dep
, maybe that's eough? Can we drop the explicit USEPKG += tlsf
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what I tried to do. However, the +DIR is in tlsf's Makefile.include and I think it doesn't get read if the USEPKG is not there. It's tricky because the contrib is a module that lives inside a package, I'm not sure if it can be done "the right way".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jcarrano I would rather have this line removed. We can achieve that by setting a dependency in Makefile.dep
:
ifneq (,$(filter tlsf-malloc,$(USEMODULE)))
USEPKG += tlsf
endif
This resolves the dependencies in the correct order.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That does not work. The Makefiles in the tlsf
directory only get read if USEPKG += tlsf
. In the other packages that have contrib directorties, the contib gets added to USEMODULE
always if the parent package is used.
It is a limitation of the current build system: if a package has an optional submodule, then the package and the module must be explicitly selected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But when I apply my proposed code snipped, then it still builds and executes for me..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have to put it around line 726, before the call to
-include $(USEPKG:%=$(RIOTPKG)/%/Makefile.dep)
where the USEPKG
statements are resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In case it wasn't clear enough: I was talking about the main Makefile.dep
in the RIOT root
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I didn't know that file existed. I wish I could keep all of TLSF inside pkg/tlsf without having to touch global files, but I'll do it anyways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wish I could keep all of TLSF inside pkg/tlsf without having to touch global files, but I'll do it anyways.
I understand your motivation, but it looks nicer and is less error prone if you only have to use USEMODULE += tlsf-malloc
in the user application instead of also specifying the package (:
And we already have this global depencendy file .. so let's make use of it.
I like the idea of using TLSF not only as a malloc-like implentation. What I'm not sure is the implementation in tlsf_g* and memory management functions aliases. Having multiple global memory allocators seems to be a rare scenario IMO, considering the fact these pkgs add their fingerprint in memory consumption (TLSF is around 3 kb). What could be is a global allocator and another functionality that strictly requires an isolated heap. But a global malloc implementation still allows to use tlsf_* functions directly from the pkg. That way, USEPKG += tlsf-malloc implements the stdlib functions with TLSF, but there could be cases where only "tlsf" is required. |
@jia200x I did the global allocator thing because that is what was already done, so I supposed there was a good reason (and maybe there is, the system allocator may be better on average than TLSF, but TLSF has a predictable O(1) performance. I agree that there's probably no reason to have both the original malloc and tlsf_gmalloc, but the original code allowed the user to rename the global memory allocators by a define that was turned into a prefix:
|
Yes, I meant to leave these functions with their stdlib name (malloc, free, etc) rather than these tlsf_g* names. Basically is "implementing missing stdlib from a pkg" rather than "implementing a global allocator that points by default to stdlib". The first approach is only a turn on/off in Makefiles. I'm aware this behavior comes from the original implementation. What do you think on leaving it this way? |
@jia200x I think that what you are saying makes more sense. It also simplifies the code. I'm not sure I'd add the weak attribute like oneway malloc does, because generally one would not want to override TLSF. As an aside comment, after seeing this definition, I was trying to avoid |
@jcarrano yes, I agree with you. I would leave it as "strong" definition, since the TLSF malloc implementation would have the same weight as other global implementations. |
@jia200x The tlsf_g* functions are gone now. |
* | ||
* If this module is used as the system memory allocator, then the global memory | ||
* control block should be initialized as the first thing before the stdlib is | ||
* used. Boards should use tlsf_add_global_pool() at startup to add all the memory |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In fact, I think this could be in auto_init modules. For the CCN example, this avoids the need to call tlsf_add_global_pool. If so, this function could be renamed to tlsf_malloc_init. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not familiar with auto init. When initializing, tlsf_add_global_pool should be called with an address that depends on the memory map of the chip.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it OK to merge this without auto init support? Maybe it can be the subject of a future PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, sure. Could be done in further PRs
I just tried it. Seems to work OK ;). And code-wise is fine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK once my comment is addressed
ad4977a
to
1d63385
Compare
Shall I squash? |
yup, go ahead! 👍 |
- Cleanup package makefile. - Download directly from git. - Remove giant patch. - Implement malloc function as a contrib package. - Update ccn example. - Update ps command.
1d63385
to
cf686bd
Compare
What's wrong with cppcheck nowadays? |
Let's skip the broken cppcheck output for this PR. Just unrelated false positives. ACK => GO |
Refactor and cleanup of the TLSF package
The TLSF package has a big patch that amongst other things, changes the TLSF api and removes the possibility to have private heaps. It also adds an implementation of the system malloc, that is not being documented because it lives inside a diff.
This PR:
The original TLSF code is left practically unmodified. The only usage of TLSF in core riot is in the CCN example, which I have tested and still works.