From owner-cvs-all Tue Jan 12 04:00:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA07152 for cvs-all-outgoing; Tue, 12 Jan 1999 04:00:55 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from critter.freebsd.dk ([212.242.41.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA07147 for ; Tue, 12 Jan 1999 04:00:53 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id MAA00481; Tue, 12 Jan 1999 12:23:11 +0100 (CET) To: Garrett Wollman cc: Nate Williams , committers@FreeBSD.ORG Subject: Re: Another approach... Re: sysctl descriptions In-reply-to: Your message of "Mon, 11 Jan 1999 14:46:08 EST." <199901111946.OAA15004@khavrinen.lcs.mit.edu> Date: Tue, 12 Jan 1999 12:23:11 +0100 Message-ID: <479.916140191@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk I still think that to go ASN.1 is to go very far, and unless we are committed to support SNMP as default and all the way... >For the oid representation, what we have now works perfectly well and >avoids lots of unnecessary compaction; the extensible integers >business in BER and company doesn't serve any purpose for us. Hasn't it already been ruled once in IETF that you will never need more than 32bit for OID's ? I recall Jeff Case telling me (something like) that a long time ago... >In a lot of these cases, it makes more sense to create some sort of >configuration file which can be loaded by the boot loader. (In >particular, I'd like to see the IPFW goop compiled into a BPF program >and then loaded by the boot loader so that it is already configured >before interfaces are brought up. This would have saved a lot of pain >a year ago...) I would still like to see somebody run a performance test on ipfw, ipfilter and BPF compiled rules before we get to that point... >> That leaves in essence variant symlinks (as known from Apollo/Domain) >> for instance: > >> ln -s '/usr/${arch}/bin' /usr/bin > >> and other such stuff. Getting the kernel to yank the "${arch}" from >> the users environment would not be easy, if even the right thing to >> do, so probably a special name-space for these variables might be >> needed. > >Which we already have through the magic of amd. Yes, for ${arch}, but not for ${my_random_var} and not on a per process basis like you do on Apollo/Domain. There were a set of LIBC hacks at one time which made a pretty good emulation of it in userland, that may be the best way to do it, if we need it. It's one of those "neat, but you CAN do it other ways without hacking the kernel" things. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message