In message <8725685F.005CF1B5.00@d53mta03h.boulder.ibm.com>,
breed@almaden.ibm.
com writes:
+-----
| > parsed! Easly parsed? By what? AWK? SED? or should the procps
| > utilities beeing implemented in damn PERL? (Some loosers who
|
| 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.
+--->8
And don't laugh at it: I have Perl ps scripts for Solaris, DU, and Linux
which live in AFS and run on an AFS-based miniperl for use on
possibly-hacked systems. The Solaris one has been quite useful....
| > And then there is the phenomenon of proliferation of /proc items.
| > Just an example...
|
| 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
+--->8
I find all the whining about sysctl vs. proc rather interesting when
compared to the following that appeared on BUGTRAQ recently. Let the flames
begin!
Date: Wed, 29 Dec 1999 12:05:51 -0500
From: "Greg A. Woods" <woods@MOST.WEIRD.COM>
Subject: Re: Wmmon under FreeBSD
To: BUGTRAQ@SECURITYFOCUS.COM
[ On Friday, December 24, 1999 at 20:27:01 (+0000), Dominic Mitchell wrote: ]
> Subject: Re: Wmmon under FreeBSD
>
> Under modern BSD4.4, the preferred method is using sysctl(3),(8), as
> opposed to kernfs.
That's not completely true and misses the bigger picture entirely.
According to McKusick, Bostic, Karels, and Quarterman the "sysctl()"
interface is indeed designed to resolve the problems associated with
giving read, and especially write access to all of /dev/kmem (even if
through a set-user-id program that restricts what any given user can see
or do for any given purpose).
However the primary use sysctl(2) is actually put to in 4.4BSD is for
accessing information about networking protocols, and for allowing
user-level programs to write to kernel data structures (and thus affect
run-time configuration changes) after the security level of the kernel
has been raised such that writes to /dev/kmem are impossible.
If indeed sysctl(2) had been intented as the primary interace to all
kernel memory structures however they would not have implemented /kernfs
and /procfs. Note that no mention is ever made of ever using sysctl()
to implement utilities such as "ps".
In later analysis it has become obvious to many people that even though
sysctl() provides a hierarchical namespace, it isn't quite as useful as
it would be if it were actually a virtual filesystem providing not only
a hierarchical namespsace, but all of the other semantics of a
filesystem as well.
Indeed many other systems have gone on to show that a true virtual
filesystem interface to kernel subsystems has many advantages over even
a sysctl()-like interface that's restricted to binary programs and
perhaps a single, but hopefully generic, user-level interface tool.
-- Greg A. Woods+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
-- brandon s. allbery os/2,linux,solaris,perl allbery@kf8nh.apk.net system administrator kthkrb,heimdal,gnome,rt allbery@ece.cmu.edu carnegie mellon / electrical and computer engineering kf8nh We are Linux. Resistance is an indication that you missed the point.
- 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/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:11 EST