On Wednesday, 21.10.2015 at 14:39, Antti Kantee wrote: > The problem it was trying to solve was developers doing quick iteration. > Remember, *you* were concerned about that developer convenience factor going > away. If now two weeks later nobody is interested in iteration anymore then > it makes complete sense to not have such a tool. If so, the thing that > makes *the problem* go away is the attitude change. Shifting goal posts is a > different way of reaching the goal (and sometimes a completely valid one). > In this case shifting the posts would probably simplify a lot of things, > like I already wrote in the rumprun-rumpbake-axis thread. > > Here's the relevant mail, if someone wants to refresh their memory: > https://www.freelists.org/post/rumpkernel-users/fixing-the-rumpbakerumprun-axis,4 > > So does anyone care about the "quick iteration" going away? (I don't)
I still care very much about a tool to facilitate quick iteration for developers (and more). In fact, I think it's absolutely essential for wider adoption of rumprun by developers or sysadmins who do not necessarily have systems programming experience. However, it is now clear to me (and your "Rise and Fall of the OS" article helped with that) that any such tool involves introducing policy of some kind (e.g. "convention over configuration", "autoconfigure everything", ...) and that such policy should be implemented at a higher layer built on top of (and possibly developed independently from) the rumprun stack, not as part of it. It follows from the above is that config.c should be an optional, swappable, component, but I take it that's not controversial in any way?
