[KLUG Programming] Pthreads problem

[Robert G. Brown]

On Fri, 02 Jan 2004 07:00:51 -0500, Peter Buxton <somercet@core.com> wrote:

>Please read the first three messages (Kleen, Torvalds, Love) before
>replying to me:
>http://www.ussg.iu.edu/hypermail/linux/kernel/0307.1/0963.html
OK, done.

>I'm posting while tired, and that is almost always a mistake, but...
>ah, well.
I'll be nice! :->

>On Thu, Jan 01, 2004 at 06:39:28PM -0500, Robert G. Brown was only escaped
>   alone to tell thee:
>
>> It seems odd and perhaps counterproductive that you are making a case
>> for LESS abstraction where it can really help. It is probably a really
>> good idea to use sysctl in production against the day that echo into
>> /proc is deprecated, I wouldn't want to convert and test all that only
>> when the time comes. 
>Yeah, I'd hate to write a C program to convert:

>net.ipv4.tcp_syncookies = 1
>to 
>echo 1 > /proc/sys/net/ipv4/tcp_syncookies
Actually, it's probably a shell script, using sed/awk/grep and so on. Unless
you've got LOTS of hosts to migrate, doing it in C will never pay. My overall
feeling is that once you're in a position where you need to write these sorts
of things, you've missed something, and this is a way to make up for it.

>LESS abstraction, eh? Lack of use of sysctl will hurt my ability to use
>the future netsysctl, which will emit kernel RPC calls over the network?
It'll probably be easier to migrate, as we'll see...

>I have a better idea, let's:...
Start another thread for that one! :)
.....
>more APIs != more abstraction
That's true, but BETTER APIs include some abstraction.
"The early bird gets the worm, but the SECOND mouse gets the cheese!" :)

>Nah... why do something like creating a file-sharing protocol that JUST
>DOESN'T SUCK?!
That's fine, and another topic. I don't want to fix the whole world at once,
just a wee little bit of it, at a time, hopefully in advance.

>> Maybe you only intend to use it for online hacking; perhaps it's time
>> to get into the habit of using sysctl there, too...
>I'm very curious to know where you and Adam got this misinformation that
>` echo > /proc/something ` is a menace to users everywhere.
Now, now, let's not blow this thing outta proportion. I don't think it's a
"menace to users everywhere", but I do know that if it were to ever change,
it's one of those time killer maintenance tasks that NO ONE will understand, 
unless they know the systems really well.

Now, as for where I got the idea that echo isn't the best way to set kernel
parameters, I'll cite 30 years of programming, 15 of them involved with stuff
like object-oriented design (which includes a lot of abstraction-related
stuff), studying enough about programming languages to have been involved in
a couple of language development and implementation efforts. I know at least 
some syntactic problems when I see 'em. However, this is not a big deal, but
I do believe in keeping out of trouble by being proactive...

I'm sure Adam (who is ,as far as I can tell, is not burdened by an excess of 
reticence) will tell you his reasons.

>Not from anywhere in the kernel, that's for sure -- I just grepped 2.6.
Nah, I don't hafta look at any source code to spot a syntactical and
programming "gotcha", and that's what echo <value> |>| <destination> is.

>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.
>
>2. (This space left intentionally blank.)
I'll fill this one in for you. 
I don't have bad things to say about /proc, and I probably won't have 
bad things to say about the successor to /proc, whatever that is going
to be.  I don't think /proc is a bad abstraction itself, and the notion
that regular unix-like tools will work on a lot of /proc does have a 
certain kind of charm.

My problem is with echo and redirection syntax. It's too low level for
my taste, at least in this application. I can do a lot more with

name=value
or
procedure name value

Because I can capture all the parameters. Redirection, in this case

procedure value > name

PREVENTS me from doing so. I can never (as far as I know, and it's going to 
be a revelation if someone can tell me I'm wrong) write a procedure that
will give me access to the "name" in the above expression. This means that
I can never introduce my own constructs, or write any code to act as an
intermediary this purpose.

Actually, this is what sysctl does. it IS a procedure that I can not only
use, but emulate. I can also replace it if I want to, introducing another
layer if needed. 

Before I knew about sysctl (maybe before it was even introduced), I wrote 
a script which looked like this:

root@gummo bin]# cat setkernel
#!/bin/bash

echo $2 > $1

 -----

and to use:
setkernel /proc/sys/net/ipv4/ip_forward 0

Simple and clear! When I learned about sysctl, did I worry about changing 
all the scripts (2, maybe 4 per host, but there are a lot of those around
here, and at customer sites) out there? Nah! I simply modified the setkernel
script, tested it, and I was all set. The tough part was distributing it! :)

The kernel folk (Kleen, et al) have their own concerns, and when they make
up their minds (or change them, next year) my scripts don't need to be altered,
because I recognized a reasonable abstraction when I saw one, and then used it.
All I will have to do is change and distribute setkernel again.

So the second reason is that sysctl, like setkernel, normalizes syntax, and as 
a result makes stuff easier to maintain. I can replace it easily. I can also 
use it to protect the system from someone placing dumb values into some 
pretty sensitive places, by making setkernel a bit less trivial.

>sysctl makes scripts work without modifying /etc/fstab, which is Good.
>That's it.
Actually, that may be enough of a reason...

>`cat /proc/slabinfo` shows you things `sysctl -a` will not.....
Yes, yes, all given. None it it speaks to the point I've written about above,
but that's no problem.

							Regards,
							---> RGB <---