Subject: Re: Enhancing sysctl support in ld.elf_so
To: None <firstname.lastname@example.org>
From: Charles M. Hannum <email@example.com>
Date: 06/21/2004 19:27:16
On Monday 21 June 2004 13:25, firstname.lastname@example.org wrote:
> On Mon, Jun 21, 2004 at 09:05:17AM -0400, Christos Zoulas wrote:
> > On Jun 21, 1:12am, email@example.com (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
> 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.