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

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Fri, Oct 31, 2014 at 2:28 AM, Masao Uebayashi <uebayasi%gmail.com@localhost> wrote:
> On Fri, Oct 31, 2014 at 1:33 AM, Antti Kantee
> <pooka%homeworld.netbsd.org@localhost> wrote:
>> On Thu, Oct 30, 2014 at 11:14:50AM +0900, Masao Uebayashi wrote:
>>> On Thu, Oct 30, 2014 at 10:51 AM, Christos Zoulas <christos%astron.com@localhost> wrote:
>>> > In article <20141030012621.0982E9A%cvs.netbsd.org@localhost>,
>>> > Masao Uebayashi <source-changes-d%NetBSD.org@localhost> wrote:
>>> >
>>> > Re: constructors/destructors:
>>> >
>>> > Using them will create a portability constraint on elf. This has
>>> > the implication that rump will not work on some platforms.
>>>
>>> Could you show me an example failure senario?  What do you propose instead?
>>>
>>> I heard that rump fixed linkset problem using .ctors/.dtors.
>>
>> I heard something different.
>>
>> A toolchain problem was fixed by using __attribute__((constructor))
>> to reach the contents of link sets in userspace dynamically linked
>> environments where generating __start/__stop was not possible.
>> Regular link sets are still preferred, as they require less magic
>> from the runtime.
>
> OK.
>
>> 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.
>
>> The problem TODO lists
>> is "random ELF sections (with potentially long names) in the final
>> kernel".  Is that a problem?
>
> I may misremember it but was it Mach-O specific?  The "long name" part
> may be irrelevant.  But I still *feel* linkset should be done in a
> better way.  I'll revisit this when I will look closer at moduler vs.
> sysctl.

pooka@ is always far ahead & already fixed modular-vs-sysctl problems.

Now my complaint about linkset is that it doesn't properly put linkset
sections under .text/.data/.bss, etc.

I also want to utilize linker script in general, as said in TODO.