[KLUG Programming] Pthreads problem

[Robert G. Brown]

On Sun, 04 Jan 2004 16:08:13 -0500, Peter Buxton <somercet@core.com> wrote:

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

But are all implementations of /proc, regardless of platform, the same?
The answer to this is (as it is almost guaranteed to be, even if it was
not explicitly stated) "no", then you've got another rather argument in 
favor of abstracting it.

>...will never go anywhere.
"Never" is a very strong word, and we've seen it violated often.

>> Of course you could argue that kernel tuning parameters 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.
Certainly so, and yet ANOTHER reason for abstracting /proc out of 
production scripts where possible.

>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....
A kind of turbulence that ought not, IMO, buffet production scripts.

>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.
Certainly so, the biggest worries are:

1. Typographical errors when entering values into an unprotected 
   interface, causing unexpected or harmful side-effects.
2. Maintenance time and costs related to scripts which set kernel
   values, usually under some pressure.
3. Script portability.

These are not fundamentally kernel issues, and abstracting /proc away
isn't, strictly speaking, an issue of great interest to kernel imple-
mentors. However, they ARE of interest to anyone building on top of
that.

>Tracking new values and obsoleting old ones, and verifying
>correct/incorrect/buggy values, is their bete noir.
It may well be, as far as maintaining the integrity of kernel space
is concerned, but how does the initiator of a setting find out that
an error as been detected, or a setting rejected, with an interface
like echo?

These may not be issues for the kernel team, but they are for those who
have to write (and maintain) scripts, not only in Linux, but for other 
OS'es, too.
							Regards,
							---> RGB <---