|As much as I hate jumping into another man's argument, I feel compelled to answer this one.
The problem with saying things like this is that somebody comes along with more experience. I'll see your 14 years and raise you 31 more. I've been doing this since 1967 on various machine types, mostly on kernel / monitor / core / OS, whatever you wish to call it. And yes, some of my kernel code has been into space.
Quote:When you have as much experience as me in the kernel I might listen to you
Allocating from something called heap / common storage / pool / whatever is always slower than just adding / subtracting a size from the stack pointer. Plus, the pool is usually one shared resource so for multithreaded or multiprocessor kernels some sort of locking mechanism is needed to prevent corruption of the basic allocation / deallocation structures. Add in the possibility of doing allocations at interrupt level too and you complicate the locking mechanism further.
I've also dome a fair amount of kernel performance analysis over the years and guess what it reveals as a common bottleneck in kernel programming, heap allocation / deallocation. These are places where one would concentrate the efforts to find smarter and faster allocation methods, split poole, etc. And even though better algorithms have developed over the years, carving small arrays / structures / blocks of code on the stack just flys over calling pool allocation.
Now it is true that you need kernel pool for longer life objects and maybe for things too large to be of practical use on the stack but please don't argue that all things must always go on one place over another, that's just too many absolutes. Sounds more like a religious argument then a logical one.