On Fri, Oct 31, 2014 at 1:33 AM, Antti Kantee <po...@homeworld.netbsd.org> 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 <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.
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. > *) you probably also heard that rump kernels have constructors with > priority levels, implemented using link sets Do you hardcode the priority?