On Monday 21 June 2004 13:25, cube@cubidou.net wrote:
> On Mon, Jun 21, 2004 at 09:05:17AM -0400, Christos Zoulas wrote:
> > On Jun 21,  1:12am, atatat@atatdot.net (Andrew Brown) wrote:
> > -- Subject: Re: Enhancing sysctl support in ld.elf_so
> >
> > | >So we should leave things as they are.
> > |
> > | meaning that ld.elf_so won't use sysctlgetmibinfo() (or, by extension,
> > | sysctlbyname())?  that means that any node that ld.elf_so will ever
> > | look up will have to be assigned a static mib entry, and that
> > | ld.elf_so will continually need to be updated (along with the #defines
> > | that describe the static mib) to be able to traverse it.  that's
> > | tricky, and was done wrong in the past (cf, the vfs.lfs nodes that i
> > | "found" when converting everything which weren't previously available
> > | because code to find them was never written).
> >
> > When was ld.el_so last changed? I don't think that it gets changed that
> > frequently.
>
> That's the point.  Using the new API, you'll never have to recompile/update
> ld.elf_so when the sysctl tree layout change.  So you'll never forget to do
> it.
>
> The "load library on sysctl value" currently allows little more than
> loading libm386 with libm and the correct arch lib on sparc.  It can be
> made more useful without much trouble apparently.  That's all this thread
> is about.

Adding extra memory requirements and startup overhead for EVERY SINGLE EXEC() 
is not a reasonable tradeoff.  This is definitely a non-starter.