On 2019-10-13 01:18, Joerg Sonnenberger wrote:
On Sun, Oct 13, 2019 at 12:46:24AM +0200, Johnny Billquist wrote:But if you use alloca(), you will have to check what size you'd like to allocate, and not allocate more than some maximum amount, I would assume. Or do you really think that it is ok to just let it try no matter what amount is decided you want to allocate? And if you figure out an upper limit, then you might as well just define an array of that size in the function, and be done with it.All nice and good, but it doesn't help with the original problem. How to deal with dynamically sized data when there is no dynamic allocator. Without context, it is impossible to know if "dynamic size" means a reasonable sized string, a list of memory segments etc. As such, it is impossible to say if alloca (or just defining a fixed size array or whatever) is reasonable or not.
I don't agree. No matter if we can tell what dynamic size means. We cannot allow allocation of arbitrary sized data on the stack. We know there is an upper limit before the system will crash. So either we immediately go for that limit (if we think we need that much), or we try to play dynamically, with a limiter at that limit. Plying it "dynamically" with a limiter then does not really gain us anything, so why do it? That was my point.
Dynamic data in a kernel is problematic. Always. You always will have limitations on it, which are more restrictive than anything people write in user land. alloca() don't change that.
If a fixed memory chunk isn't good enough, then alloca() will not really be any better, since it can't give you more anyway. It just does it (slightly) differently.
If we need more memory than can be allocated on the stack, then you need to come up with other solutions. Just replacing a static size allocation with a call to alloca() don't solve any problem.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol