On Monday, 25.01.2016 at 23:42, Antti Kantee wrote: > On 25/01/16 12:29, Martin Lucina wrote: > >Apart from the unresolved question of the JSON parser and rumpconfig > >dependencies on libc interfaces, is there anything else that's > >fundamentally blocking this work being merged to master? Specifically, > >notwithstanding the current implementation (which can be changed), is > >there anything unacceptable about the specification as the future *public > >interface*? > > The problem, at least for me, is that the proposal is too massive for me to > manage to put enough time aside for to process atomically and reach 100% > confidence that I thought of everything that I possibly could. Therefore, it > goes on the pile of "I can get something done today or I can write one > email". It's easy to guess which one wins ... sorry :(
As I write at the beginng of the spec text... The intent of this specification is to define the minimal "lowest common denominator" for configuring a rumprun unikernel. It is expected that special case configuration will be performed by the programs baked into the unikernel on a case-by-case basis rather than specified here. ...I don't think that "100% coverage of all cases" is achievable or desirable. By definition, if we wanted to support "all possible things one might want to do" we would end up with a programming language embedded in the specification. So, we will have to make some calls along the way on what stays in scope and what goes out into "write custom code to do that". > Can we do a divide and conquer discussion where we go over the top-level > spec blocks -- just them completely ignoring the implementation for now -- > one-by-one in separate threads? That's good -- discussion about the spec as an interface is what I was hoping for from the original post, rather than getting sidetracked on implementation. > The other approach I can propose is that a few dozen people start shouting > comments. IOW if 90% thinking is 10% of the work, with 20+ people we'll > reach quite a high probability that all bases were covered. Of course, that > depends on a few dozen volunteers on this list ;) > > After we get the spec nailed down, let's take it from there and figure out > the other points in order of diminishing carved-into-a-rock-ness to get your > revamp into the tree. > > Assuming we don't get dozens of commenters overnight, can you start by > posting the first thread, and a new one every two-or-so days after the > comments on the previous thread die down? That sounds like a sensible way forward. I'll start with the first top-level block, "rc" and go on in the order they're listed in the proposed spec at [1]. I will incoporate comments that people have already made in this thread into the various threads (and in parallel also work on implementing/syncing those changes on the branch [2]). I'll also add any issues or concerns I've thought of so far, including applicability (or not) to kernonly mode configuration. > It's always difficult redoing something because you need to be sure it's > better than the left-handed first attempt :/ True. This is why I've kept the 'rumprun' launch script synchronized with the new spec -- as a way to keep 'backwards compatibility' while we iterate on the spec. [1] https://github.com/rumpkernel/rumprun/blob/mato-wip-rumprun-config/doc/config.md [2] https://github.com/rumpkernel/rumprun/tree/mato-wip-rumprun-config
