Date: Fri, 12 Jun 1998 19:36:09 -0400 (EDT) From: Chuck Robey <chuckr@glue.umd.edu> To: Mike Smith <mike@smith.net.au> Cc: Nate Williams <nate@mt.sri.com>, dyson@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: kernfs/procfs questions... Message-ID: <Pine.BSF.3.96.980612192358.2140O-100000@localhost> In-Reply-To: <199806042232.PAA02556@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 4 Jun 1998, Mike Smith wrote: > > > > But users aren't expected to use gdb/nm/hexdump, but sysctl is. Many of > > > > these parameters *should* be tweaked to get better performance, avoid > > > > errors, etc... > > > > > > > Only some of them, if any. > > > > Again I say, if they're not meant to be touched, then don't expose > > them. It's stupid to expose something that is useless for 99.9% of the > > population. > > They're no more or less "exposed" than, say, the diskslice ioctls. If > they serve a function as (eg.) maintenance tools, then they're superior > to the Sun "just use adb on the kernel and set this to that..." > approach. > > > It's not my place to enforce, but if it were I'd start removing any > > sysctl's that weren't documented/used. As Mike pointed out in private > > email, there are 434 sysctl nodes in our system, and 20 of them are > > documented one way or the other. The rest are magic. > > > > I think of sysctl as a bunch of big global variable, or OPTIONS in the > > kernel config file. If it isn't documented, it isn't needed. Could I make a suggestion? How about allowing the documentation on sysctl to be outside the norm a little, so as to make it much easier for folks adding new ones to make the doc? This eliminates the need to add the troff/man formatting, which can bre a pain. Something like a file in /usr/share/doc (maybe /usr/share/doc/sysctl.list) where every new knob needs to get a short def, of a form that encourages (at least) a minimum in completeness? This would allow huge howls if a new sysctl was implemented without a doc entry. The man page on sysctl could refer to that file, and everyone wouldn't have to stumble over troff. If you don't want the doc in a separate file, it _could_ go in the man page. I know troff well enough to do that, but I'd have to be a short term pest while getting the info. Won't do that without your agreement that it's necessary. I'd really rather have it in a separate file, so documenting new ones could have a firm requirement of documentation (because there'd be no excuse not to do that). I think, personally, the fs route is overkill, myself, but the doc angle is the real point, isn't it? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic (FreeBSD-current) (301) 220-2114 | and jaunt (NetBSD). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980612192358.2140O-100000>