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.
> 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.
> 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.
> 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.
> 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.
my $.02
ben
-
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 : Fri Jan 07 2000 - 21:00:09 EST