Date: Wed, 08 Nov 1995 20:29:44 +0100 From: Poul-Henning Kamp <phk@critter.tfs.com> To: Bruce Evans <bde@zeta.org.au> Cc: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/kern kern_sysctl.c Message-ID: <3417.815858984@critter.tfs.com> In-Reply-To: Your message of "Thu, 09 Nov 1995 06:17:51 %2B1100." <199511081917.GAA05935@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> >Bruce I share most of your concerns, but disagree on the cure.
>
> >Some specifics:
>
> >Yes, I rely on compiler magic for the sysctl variables. I live in the
> >nineties, and we have to move forward. I looked at other options, and
> >they were uglier.
>
> Linker sets are very old technology. They are useful for static linking
> and configuration, but we're trying to get away from those. Consider an
> lkm that adds some sysctls. Linker sets are no help. First, they can't
> work for dynamic linking because the vectors are statically allocated
> and can't be extended. Second, if they could be extended, then you
> would have to process them every time items are added or removed.
Well, how would you dynamically add something to a switch() {} ?
I may have forgotten that in my last email but dynamic mgt of sysctl
vars is certainly in the plans. I will have to malloc storage for a
replacement linker-set of course... too bad I can't free the old one.
> Current processing consists of sorting the vectors and probably only
> works once (later, there may be pointers into the vectors...). I
no.
> think it is better for the primitive operations to be addition and
> removal operations on a tree. The `sysctl_' linker set would just
> give a list of things to be added to the tree initially.
no, wastes too much storage. Been down that road once. You end up
having to store the entire name in each entry. Bad for your RAM.
> More importantly, the current implementation makes it very difficult
> for an lkm (or a syscall) to add sysctl variables. E.g., changing
> CPU_MAXID requires recompiling; if CPU_MAXID was made a little
> larger to allow for more variables, the variable numbers would have
> to be allocated at compile time so that they aren't ambiguous.
But not for long. Watch this space :-)
> >I do plan to (have somebody else) add sysctl-variables to the userconfig
> >editor.
>
> The ability to configure sysctl variables (not just their values) there
> would be overkill :-).
No, actually not. sysctl variables may start to do a lot more work than
they do now pretty soon.
We used to say that you need to be able to crawl before you can walk,
I'm doing that now...
--
Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team.
http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox.
whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc.
Future will arrive by its own means, progress not so.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3417.815858984>