On Fri, Oct 31, 2014 at 3:00 AM, Antti Kantee <po...@netbsd.org> wrote: > On 30/10/14 17:28, Masao Uebayashi wrote: >>> >>> Is there a problem rototilling config is going to solve over what >>> is possible with the existing mechanism (*)? >> >> >> You're welcomed to fix any problems without rotorill and/or breakage. > > > You're not answering the question.
For one, to localize related objects (*.o). Now config(1) just collects all *.o and link them into "netbsd". I want to collect for example machdep related objects to be located in the lower address. There might be a way to achieve this without touching config(1). But I think reusing information in config(1) definitions is the most straightforward. (I'll try to state this more clearly in TODO.) >>> *) you probably also heard that rump kernels have constructors with >>> priority levels, implemented using link sets >> >> >> Do you hardcode the priority? > > Yes. They are easy to hardcode, as you can observe from working code, and I > don't see the need for a complex mechanism. There's really only ~10, and > even less for the full kernel, since you don't need to worry about things > like "will vfs be present" or "when do i configure the address for lo0". > Even if you'd want to worry about for example the latter one, how would you > express it with config? The latter is impossible. Module dependency is only about init code order. > But let's consider some magic values are generated by config in a fashion > which works in a non-monolithic build. How will anything be different if > you touch or don't touch linksets, i.e. how is your question relevant in > this discussion? > > Cleaning up init_main() is an ambitious project. I don't know if config is > the right tool for that (I don't know it's _not_, either). I do know that > it's complete orthogonal to how linksets are implemented. I'm discussing multiple things and confusing contexts. My question about linkset is more like: "using linker is good, but why should it be linkset?". I don't understand why their sections are not under .text/.data/.bss. I don't get why their section names have to be exposed in the resulting "netbsd". In any case I'll remove "linkset" part from TODO to not confuse people.