[KLUG Programming] Pthreads problem

Adam Williams programming@kalamazoolinux.org
Sun, 04 Jan 2004 13:02:43 -0500


> I'm very curious to know where you and Adam got this misinformation that
> ` echo > /proc/something ` is a menace to users everywhere. Not from
> anywhere in the kernel, that's for sure -- I just grepped 2.6.

Calling it a "menace" is a little harsh.  There was a thread on one of
the developement mailling lists some time ago (~2 years now, don't even
remember) that stated using sysctl was safer, it protected you from
writing terribly absurd values to certain things whereas with echo it
was easier to screw up and render a system no-op.

> Now, for the record, let's review the difference between sysctl and
> `echo > /proc/something `:
> 1. sysctl will work whether /proc is mounted or not.

Correct, or possibly even when /proc is no more, or is not writable.  Or
when /proc changes its structure.  It appears this isn't going to happen
soon,  but there were rumblings that 2.6.x would change /proc
substantially.  Will 2.8/3.0?

Of course you could argue that kernel tuning paramters are kernel
version specific anyway.  Many settings in 2.2.x just don't matter in
2.4.x anymore; I'm sure the same will be true in 2.6.x as things become
for fundamentally dynamic.

> `cat /proc/slabinfo` shows you things `sysctl -a` will not. This kind of
> kernel publishing doesn't fit in current sysfs and sysctl would be
> awkward and suffer from poor discovery.

Sure but this is just a shortcoming in Linux overall, and why AIX
kicks-its-a$$ as far as managability goes.  No places holds
"everything".  Tuning an OS like AIX is much more a step-by-step
procedure than tuning "cancerous" :) Linux.

> sysfs will not replace proc, though it is a replacement for some
> misshapened /proc features: it is entirely hardware related. Also, sysfs
> is NOT writeable and, unless I am grossly misinformed, it will not be by

I believe you are correct.  My impression from various articles is that
some kind of bus like DBUS will eventually find its way into the kernel
and that will be the way to change values, load/unload modules, etc... 
Could be wrong,  and the future is subject to change-without-notice.