Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/usr.bin/config



On Fri, Oct 31, 2014 at 3:00 AM, Antti Kantee <pooka%netbsd.org@localhost> 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.


Home | Main Index | Thread Index | Old Index