Reusable Stack

[aviramha]

This is a draft of what I'm proposing to do as part of #73
This is currently useful for us, so if maintainers are okay with this change (generally) I will add docs and mark this as ready for PR.

[nagisa]

Right, I’m not entirely sure if exactly this is something in scope for stacker specifically. The large part of its value proposition, I feel, is how simple it is.

I do agree, however, that a lot of functionality currently in stacker could be more stand-alone. Allocating stack-like memory regions for example is something that would be useful outside of stacker and splitting it out into a crate has been on my to-do list for ages now.

So ultimately the question I’ve is: is it possible to split out some the functionality stacker provides on top of plain psm in a way that your use-case and requirements can be served trivially without changing the API of stacker itself?

[aviramha]

Right, I’m not entirely sure if exactly this is something in scope for stacker specifically. The large part of its value proposition, I feel, is how simple it is.

I do agree, however, that a lot of functionality currently in stacker could be more stand-alone. Allocating stack-like memory regions for example is something that would be useful outside of stacker and splitting it out into a crate has been on my to-do list for ages now.

So ultimately the question I’ve is: is it possible to split out some the functionality stacker provides on top of plain psm in a way that your use-case and requirements can be served trivially without changing the API of stacker itself?

I'm pretty sure I didn't break/change any existing API (that is exposed externally). If I did, it happened by accident and we can fix it probably.
Edit:
Oops, didn't notice you said to a different crate. I think it could be done but far more easier to have the building blocks in stacker - as long as the exposed API is easy (and it stays easy in this PR I believe) I don't see any reason to create another create..

[nagisa]

I'm pretty sure I didn't break/change any existing API (that is exposed externally).

NB, what I said was “changing the API”, not “changing the existing API”, which includes adding new API surface as well.

I think it could be done but far more easier to have the building blocks in stacker - as long as the exposed API is easy (and it stays easy in this PR I believe) I don't see any reason to create another create..

So, a good reason would be composability with crates other than stacker itself, without necessarily pulling in the rest of stacker. OTOH, admittedly stacker is very slim as far as crates go anyway…

---

All that said, if you’d rather see this land as proposed, I’d be reasonably happy to see this fleshed out and landed. I can’t promise that the new functionality will stay in stacker proper forever. One of these days I might find some time and finally go through decomposition of the crate, which might result in this API getting changed and/or moved to elsewhere.