On Fri, Oct 31, 2014 at 2:28 AM, Masao Uebayashi <uebay...@gmail.com> wrote: > 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.
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.
