[KLUG Programming] Pthreads problem

[Peter Buxton]

Several of Adam's posts have been concatenated into one uber-reply.
Sorry if this breaks following our threads, but I'm running about and
need to save time.

On Sun, Jan 04, 2004 at 01:02:43PM -0500, Adam Williams was only escaped
   alone to tell thee:

> 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?

IIRC, you may be referring to Torvald's complaint (echoed by many, heh
heh heh) that /proc was becoming hairy. Specifically, published data
for, e.g., different brands of SCSI adapters suffered from no standard
format nor amount or type of data published.

_Sic_sysfs_. Not only is it in every 2.6 kernel, whether you mount sysfs
on /sys or not, but it is written into the kernel in such a way that
writing a device driver that WON'T show up in sysfs is apparently more
difficult than not.

> > `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.

If you think echo and /proc are the sources of that, I suggest you're
high.

Cathedral v. bazaar: changes in AIX pass through committees which ensure
that important commercial apps won't have to change too quickly.  In
Linux, even 2.4 from Red Hat sees RH backporting features like crazy:
ALSA, NPTL, O(1) schedulers. Stable? Hah!

Also, how exactly do you tune AIX? (Never having been root on one, I
wouldn't know.) Do you use big, expensive apps specifically written by
IBM to control their big, expensive OS? Do you think you might be
reduced to echo, or sysctl, if you didn't have those apps? Hmmm....

> BTW, /proc is not isolated to Linux.  AIX (at least) has one too.

/proc first appeared on Thompson and Ritchie's OG nextgen Unix, Plan 9.
Other Unices adopted it with varying modifications. I'm not sure that
Plan 9 used proc as a kernel configurator (probably not, given
Thompson's mania for simplicity over performance hacks), rather, it
published important system information, e.g.: ps(1) merely pretty
printed information in /proc (as does Linux ps). This feature meant that
ps did not have to be made setuid.  /proc is an important feature that
will never go anywhere.

(I should also note that I have a sneaking suspicion that proc, like
sysfs, is *there* whether you mount /proc on boot or no. I would have to
run some destructive test and read more code before I say so for
certain.)

> 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.

But my comment on /proc, regarding changing kernel parameters, means
that Linux/Solaris/AIX/Plan 9 kernel frobbing is highly individual, not
only to each brand of Unix, but even to each version
(/proc/sys/vm/swappiness is new to, I think, 2.6.0-test8 with C.
Kolivas' acheduler mods).

> 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.

I have not yet read the kernel code yet (but plan to) to verify that
echo can break things sysctl cannot; even so, someone who wished to
create a comprehensive library of permissible sysctl changes is chasing
a unicorn: echo(1) is not their greatest problem by a long shot.
Tracking new values and obsoleting old ones, and verifying
correct/incorrect/buggy values, is their bete noir.

Such a system would almost certainly use sysctl(2) directly for
efficiency, rather than calling it indirectly through the VFS.
Efficiency for such a (fictional) /proc-management app would be quite
different than for a hacker at the keyboard, or a script that changed
some value while doing network migration. 

> I don't think it is anywhere near 'cannonical truth' that "sysctl =
> good" and "echo {} > /proc/{}" bad.

What's the canonical spelling of canonical? Oh, yeah.... ;-)

-- 
Black Ops. Silent, undetected and above all
*untraceable* acts of system administration.