Messages in this thread | | | Date | Fri, 07 Jan 2000 18:43:09 +0100 | From | Martin Dalecki <> | Subject | Re: /proc guidelines and sysctl |
| |
breed@almaden.ibm.com wrote: > > Quotes from Marcin Dalecki (out of order) > > Speaking first hand from a past life as an admin, scripts are the bread and > butter of a good admin. And now as a writer of a lot of user code > (C/C++/Java) I see many extremely useful benefits that aren't available > elsewhere.
That scripts are a good thing if used at the proper places is a triviality. In fact I find myself typing whole shell loops blind into the command line sometimes. But this isn't the issue here...
> > Wonderfull!!!! The same data twice, albeit no one of them easly > > parsed! Easly parsed? By what? AWK? SED? or should the procps > > utilities beeing implemented in damn PERL? (Some loosers who > > don't know C would apreciate this, certainly) !!!!! > > The only thing I'm missing is adding floating point > > formats to this... > > hits the nail on the head. Perl (I love/hate it too...), AWK, SED, bash, > etc are the tools of trade. Their flexibility and rapid devel time are > perfect for the toolkit of most sys admins. I would have killed to have > /proc on the other UNIX machines I was in charge of.
If you ask me for my oppinnion on scripting languages then I can tell you: I love awk, sed and ksh. Tcl isn't bad too. But I hate perl, becouse it get's usually overused at places where a real programm would better fit. I call it the emacs of scripting... Anytime somebody wan't some wired perl stuff on his server one has too install tons of "packages" for his single buggery cgi. But again this isn't the issue here.
The issue here is: What is so inconvenient about:
echo "Free memmory is"`sysctl freemem`
in comparision the the wonderfull /proc based scripting you are talking about
cat /proc/freemem | while read TAG VALUE do case $TAG "FreeMem:") echo "Free memmory is $VALUE" ;; esac done
Written entierly from memmory for you just for show, don't please expect them to work out of the box.
You see a proper system utlility doesn't exclude you from SCRIPTING in any way! However you can argue that linux is missing such a good thing as the sysctl programm I'm reffering above too.
> > And then there is the phenomenon of proliferation of /proc items. > > Just an example... > > > Hell only God know's what they are good for! > > And there is no userland tool for this. This is the > > last thing Mark Lord added before ditching ide developement. > > > Don't tell me any sane admit will fiddle with ALL this... > > And in esp. any sane system doesn't need this degree of > > pseudo configuration flexibility. > > You would be surprised. Not just sys admins, but some user code, that does > what some people need, use the strangest info. And with drivers there are > the strangest knobs sometimes, and believe it or not people turn them. And > most often they are turned using those evil scripts.
No I don't beleve... Just again go out and compare. Many of the things which are tunable by /proc should be in fact statrtup paremteters for the kernel, setup much the way rdev was warking in the early days... and many are just there without any practical use. And then where is the documentation? I didn't call scripts evil in themself. I think that it's just entierly a silly idea to fiddle around with kernel parameters by using cat 17273 > /proc/something and not using proper shielding tools.
This sound just like a "workaround" for the fact that there is no coordination in linux between the developement of proper /sbin utils and the kernel. This is not proper interface design.
Point.
> > Maybe it appears cute as an idea to have something like this, but > > in practice something like this is inevitable > > going to result in a coding mess in esp. in an such uncoordinated > > effort like Linux. > > It's more than cute. /proc has info not available elsewhere without having > to go into /dev/kmem. And the nice thing about a file system is that (with > guidelines) people can put all their uncoordinated extensions in the proper > place. The hierarchy allows some order in the chaos.
The chaos is in the first place and therefore there is the need for this "chierarchy". Really get out there and compare linux system tuning with FreeBSD.
> > And I didn't even tell a word about the bloat/mess/races inside the > kernel > > code caused by this all... > > Actually the bloat/mess has to be somewhere. Either in userspace trying to > make sense/stay in sync with the kernel structures, or in the kernel where > it has the structures. Obviously everything shouldn't go in /proc, but > there things that are simplier either in the kernel or in user space. > > In some of the embedded projects we do space is a big issue, and /proc > actually allows us to save space by not putting a lot of tools (like ps) in > the precious flash.
You would have been surprised how much space you could sacrify by really removing all proc related code inside the kernel. Last time it was passible in linux it was about 25k code. Remember those where times where my entier kernel only took 149k or such of text... Or just do size /bin/ps on a free BSD box and compare the reslut's with the same on linux (assuming you didn't compile the procps lib as shared...) Why do you think we have currently make bzlilo instead of make zlilo now?
The first race in /proc I can think of is for example the simple fact that ps doesn't really get a true snap of the systems state, there are chances that it will change under the feets of it... Do you really remember how long it took until find /proc didn't hang the whole system anymore?!
-- Marcin Dalecki
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |