[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 1:33 AM, Antti Kantee
> 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.
> 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.
> *) you probably also heard that rump kernels have constructors with
> priority levels, implemented using link sets
Do you hardcode the priority?
Main Index |
Thread Index |