I didn't realize that the reason that one-way malloc was left one-way was that dynamic memory allocation is discouraged. I suppose I should leave it that way if that is the case.
Let me give you some context for what I am working on. I am working on implementing a TCP stack for RIOT. I am aware of the work being done in Pull Request #4744. The work I am doing to be a more feature-complete alternative to the work being done in #4744, aimed at those platforms that have the resources to support it. It is port of the protocol logic in the FreeBSD operating system, and would have support for zero-window probing, out-of-order segment reassembly, TCP timestamps, New Reno congestion control, selective acknowlegements (SACK), etc. I've already done the work to port this to TinyOS, and found that the memory overhead was ~20KB of code memory total and ~550 bytes of RAM per socket, which can reasonably be supported on some platforms. I am aware that other parts of RIOT OS use zone allocators. The allocator for file descriptors, and the packet buffer for allocating pktsnips, are two that I have been working with. In fact, I have already been trying to avoid dynamic memory allocation (I allocate the TCP state and SACK blocks from pools, for instance). I was interested in using dynamic memory allocation for the send buffer on TCP sockets. It seems wasteful to statically allocate 1-2 KB buffers for each TCP socket when most applications won't even need to use the whole thing. Rather, I wanted to make the send buffer grow as the user writes data to the socket--up to a limit, when writes start blocking. If I run out of heap space while doing this, I can just make the user block on the socket write, just as if they had filled the buffer. Using a pool or zone seems to defeat the purpose, in this case, since that would require me to allocate a static region large enough to accommodate the full size of all the send buffers upfront, which is precisely what I was trying to avoid. Just wanted to explain where I am coming from. I suppose I could make do with a static pool of memory and allocate memory from it, if dynamic memory allocation really must be avoided anywhere in the kernel. Thanks for the advice. Sam On Tue, Aug 9, 2016 at 12:27 PM, Oleg Hahm <[email protected]> wrote: > Hi Sam! > > On Tue, Aug 09, 2016 at 12:01:08PM -0700, Sam Kumar wrote: > > I noticed that there is a "oneway-malloc" module in RIOT OS. It appears > to > > be a thin wrapper around sbrk that only supports allocating memory, not > > freeing it. > > This is correct. It was originally introduced for MSP430 platforms. > > > I am doing some development using RIOT OS, and dynamic memory allocation > > would be useful to me. Is there already a module that implements dynamic > > memory allocation suitable for general-purpose use in the kernel and in > > user programs? > > Dynamic memory allocation is usually a bad idea for embedded systems (see > for > instance https://www.quora.com/Why-is-malloc-harmful-in-embedded-systems). > Within kernel context it MUST be completely avoided. > > If you really need dynamic memory allocation, you can either use the TLSF > package [1] or use a simple memory manager that uses a static memory pool > like > memmgr [2]. TLSF is O(1), but works only on 32 bit platforms. > > > If such a module does not already exist, I am willing to contribute a > > lightweight implementation of malloc, realloc, calloc, and free to > replace > > the oneway-malloc module. > > This could be a good idea indeed. :) I once had the above cited memmgr as > package in one of my private branches, but I guess I haven't pushed it to > Github. However, creating this package didn't take longer than half an > hour. > > Cheers, > Oleg > > [1] https://github.com/RIOT-OS/RIOT/tree/master/pkg/tlsf > [2] https://github.com/eliben/code-for-blog/tree/master/2008/memmgr > > -- > The worst thing about Perl jokes is that next morning you can't understand > why > they seemed so funny. > > _______________________________________________ > devel mailing list > [email protected] > https://lists.riot-os.org/mailman/listinfo/devel > >
_______________________________________________ devel mailing list [email protected] https://lists.riot-os.org/mailman/listinfo/devel
