Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!harvard!adelie!cdx39!jc
From: jc@cdx39.UUCP (John Chambers)
Newsgroups: comp.sources.d
Subject: Re: Re: Changing sysname and nodename dynamically.
Message-ID: <478@cdx39.UUCP>
Date: Tue, 18-Nov-86 12:15:28 EST
Article-I.D.: cdx39.478
Posted: Tue Nov 18 12:15:28 1986
Date-Received: Wed, 19-Nov-86 21:24:33 EST
References: <464@cdx39.UUCP> <1279@hoptoad.uucp>
Organization: Codex Corp, a subsidiary of Motorola Inc, Canton MA, USA
Lines: 59

> 						...   Many of these
> make it into products and this is even worse since it means thousands
> of people will have to live with this cruddy unportable interface,
> all because somebody got a "good idea" but didn't have the talent or
> the judgement about when to use it.
> 
> Writing to /dev/kmem is like using peek and poke in micro Basics.
> You know it works, but you know damn well that this program will not
> work on a different brand of computer.
>
While I agree with the sentiment in the abstract, I'd like to point
out that in this particular case, you are wrong.  Before posting
the source, I tested it on a number of different brands of computer.
It worked just fine on all but one.  The one where it failed turned 
out to have a bug in the memory device driver; setuname died with an 
I/O error while trying to read /dev/kmem.  So I used it on /unix, 
which worked just fine, and re-booted.

This is arguably not a case of non-portability.  If someone were to
market a version of Unix (tm) in which, say, printf("%X") bombed out,
you wouldn't claim that programs using this aren't portable.  You'd
say that the particular release of that system has a bug.

Similarly, if someone tries using on a system (Unix or other) that
lacks the utsname structure or system call, it won't work.  It'll
probably not even compile.  It also won't port to a system that
lacks read() and write().  So what?

As for the original flame, well, I agree that Unix doesn't have
the best way of handling peeking and poking into the kernel.
There should be a set of files somewhere that correspond to
the kernel's tables, so that programs can just open a table.
My little program wastes time needlessly scanning through the
kernel looking for utsname.  It would be much cleaner and faster
if there were a file named something like "/kernel/utsname" to
open.  I've heard rumors that there are some versions of Unix
where this is done, but it's certainly not standard.

There should also be a file "/proc/12345" whose contents are
the (virtual) address space of process 12345.  This would make
it possible to write at least semi-portable versions of things
like ps, not to mention debuggers.  Again, I've heard rumors
that such things have been done (and it wouldn't be too hard),
but it's certainly not very common.

If there's someone around that wants to build a Unix that does
these things, I'd be happy to send them my resume.  I'd rather
work on making things work right than just flame about how bad
it all is.

Meanwhile, we do what we can with what still isn't the OS to
end all OSs, and sometimes remind ourselves that we could be
stuck working on OS/MVS.
-- 
	John M Chambers			Phone: 617/364-2000x7304
Email: ...{adelie,harvax,inmet,mcsbos,mit-eddie,mot[bos],rclex}!cdx39!{jc,news,root,usenet,uucp}
Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193
[The following added so that an NSA computer will take notice, guaranteeing that I'll have at least one reader:-]
> cryptography, cipher, DES, homosexual, drugs, secret, decode, NSA, CIA, NRO, terrorist, Soviet, Libya, Iran.