On Thu, Oct 30, 2014 at 11:14:50AM +0900, Masao Uebayashi wrote: > On Thu, Oct 30, 2014 at 10:51 AM, Christos Zoulas <chris...@astron.com> wrote: > > In article <20141030012621.0982...@cvs.netbsd.org>, > > Masao Uebayashi <source-changes-d@NetBSD.org> 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 (*)? The problem TODO lists is "random ELF sections (with potentially long names) in the final kernel". Is that a problem? *) you probably also heard that rump kernels have constructors with priority levels, implemented using link sets