lkml.org 
[lkml]   [2000]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: /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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.035 / U:0.620 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site