From owner-freebsd-commit Thu Nov 16 01:02:30 1995 Return-Path: owner-commit Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA16309 for freebsd-commit-outgoing; Thu, 16 Nov 1995 01:02:30 -0800 Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA16288 for cvs-all-outgoing; Thu, 16 Nov 1995 01:02:25 -0800 Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA16266 for cvs-sys-outgoing; Thu, 16 Nov 1995 01:02:20 -0800 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id BAA16214 ; Thu, 16 Nov 1995 01:02:05 -0800 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tG0Co-0003wlC; Thu, 16 Nov 95 01:02 PST Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id KAA04390; Thu, 16 Nov 1995 10:02:00 +0100 X-Authentication-Warning: localhost.tfs.com: Host localhost didn't use HELO protocol To: Julian Elischer cc: peter@jhome.dialix.com, bde@zeta.org.au, CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/kern kern_sysctl.c In-reply-to: Your message of "Wed, 15 Nov 1995 13:55:11 PST." <199511152155.NAA01351@ref.tfs.com> Date: Thu, 16 Nov 1995 10:01:59 +0100 Message-ID: <4388.816512519@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-commit@FreeBSD.ORG Precedence: bulk > > Another thing I would love to make is a ability to create variables for > > user-land purposes: > > > > 0.5. Create a variable, "new" holds info. > > > > This would allow us to use sysctl as a miniature registry for information, > > for instance: > > domainname > > which crypt to use as default. > > what to do in malloc in case of an allocation error. > > anything else you can thing off... > > > > What do you people think ? > > ok this is like "System-wide" environment variables.. except that if we check on the securelvl, they are much safer than any other method... > it also means we are going to have 4 ways of doing similar things.. > 1/ environment variables passwd from init can't be relied on, anyone can change them. > 2/ sysctl variables Can be protected by securelvl, or even by their own "change-no-more" sysctl variable. > 3/ /proc and /kern could be extended to store these things /kern should die and sysctl used insted. (unless we think plan9 is the way to go :-) > 4/ I've considered extending devfs to allow access to > system stuff don't. Keep devfs for device nodes. Don't mix too much in there. > I thought about being able to extend the sysctl interface into a f/s interfac e > (just replace them dots with /) Yeah, but why ? -- 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.