I noticed there are kexec talks this year at Linux Plumbers. Kexec, kernel
boots kernel, has had a 25 year gestation in Linux, but it looks like it's
finally coming together, driven by need.
Thereby hangs a tale.
in 1977, I was working at udel with Ed Szurkowski, the first sysadmin of
the Unix systems we got in 1976 (first machine was an 11/70). Ed was a
gifted engineer and did all kinds of neat work on v6. He later went to the
Labs once he got his PhD and I lost track of him.
Ed got tired of watching the bootstrap slowness, and wrote a system call
that did the following:
1. load kernel in memory from system call argument
2. put special signature in low memory telling bootstrap "look in memory"
3. reboot via reset.
Now, this works, because back then, ROM boot code did not zero memory.
Memory was unchanged across reset. So the bootstrap could find the magic
bits and start the kernel.
I've lost the code, I carried the listings for decades but finally dumped
them. A shame.
But I'm wondering: is Ed's work in 1977 the first "kernel boots kernel" or
was there something before?
> The array size} limit that I found through trial and error is (2^15)-1.
> Declaring an array that is [larger] results in an error of "Constant
required",
On its face, it states that anything bigger cannot be an integer constant,
which is reasonable because that's the largest (signed) integer value. Does
that version of C support unsigned constants?
Doug
Hello all,
I know that this isn't strictly a "UNIX history" question, but as I am
working with historic UNIX and this list contains a great number of people
who were instrumental in its development, I figured it would be appropriate
to ask here. If there's a better place for these sorts of questions,
please let me know.
I'm trying to figure out how the array size limits are set in the 2.11BSD
pcc compiler. I've looked through quite a bit of documentation but I don't
see anything that describes this. In theory on a 16 bit system I would
think that the maximum array size would be 64K, but the actual limit that I
found through trial and error is (2^15)-1.
Declaring an array that is too large results in an error of "Constant
required", which is being produced by c01.c in conexp().
https://www.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/src/lib/ccom/c01.c
I did quite a bit of searching through the source but I was not able to
determine where this limit is being set. This is where my usual tools fall
apart. Normally since I have the source I would compile the program I want
with debugging turned on, and then do a backtrace so that I could see how
we got to conexp(). But as far as I can tell I can't get a backtrace,
since there is no option for debugging information in pcc; adb can only
tell me where a process stopped.
I would appreciate any enlightenment or pointers to other documentation.
Thanks in advance!
-Henry
> From: Rik Farrow <rik(a)rikfarrow.com>
> Was the brevity typical of Unix command names a function of the tiny
> disk and memory available? Or more a function of having a Teletype 33
> for input?
I'm not sure the answer was ever written down (e.g. in a memo); we will
probably have to rely on memory - and memories that far back are now fairly
thin on the ground by now. Perhaps Mr. McIlroy (or Mr. Thompson, if we're
_really_ lucky) will humor us? :-)
I have the impression that some of the names are _possibly_ inherited from
Multics (which the early Unicians all used before Unix existed) - but maybe
not. The command to list a directory, on Multics, is 'ls' (but see below) -
but the Multics qcommand to remove a file is 'del' (not 'rm'); and change working
directory is 'cwd'. So maybe ls' is just chance?
Multics had a 'feature' where a segment (file) could have additional names (to
the main name), and this is used to add short aliases to many commands, so the
'base name'' for the directory list command is 'list'; 'ls' is a short
alias. A list of Multics commands (with short forms) is available here:
https://www.multicians.org/multics-commands.html
I'm not sure how early that alias mechanism came in, though; my copy of
"Introduction to Multics" (February, 1974) doesn't have short names (or, at
least, it doesn't use them).
It won't have anything to do with disk and memory. Having used a Teletype, it
would take noticeably longer to type in a longer name! It's also more effort
and time. I would expect those are the reasons for the short names.
Noel
Lyndon Nerenberg (VE7TFX/VE6BBM):
Oh come on Rob, you should know that for anyone over the age of 50,
the moment you see 'dd' your brain automatically switches to JCL
mode.
===
Rob doubtless got IBM out of his system back in the
late 1970s, when I think he was one of the authors
of a shell that brought the TSO experience to Unix.
Norman Wilson
Toronto ON
On Monday, September 16th, 2024 at 6:28 PM, Henry Bent <henry.r.bent(a)gmail.com> wrote:
> ...
> I also have v9 on a Sun in TME
> ...
>
> -Henry
>
V9 you say...does your setup happen to have the on-line manpages by any chance? I don't think a surviving copy is in the TUHS archive. V9 is a tad bit fragmentary in the archive at present from what I can tell, it may be worth seeing if anything you have fills in blanks.
- Matt G.
Rob Pike:
I don't remember whether late Research Unix [dd] had -if, but Plan 9
certainly did.
===
I don't have a live 10/e system at the moment, but I have
the 10/e source tree handy. Classic parody-IBM syntax
only.
Aside: I'm curious: does anyone else have 8/e, 9/e, or
10/e running these days?
Norman Wilson
Toronto ON
> Who created the "cat" command and did they have the
> word "catenate" or "concatenate" in their heads?
Ken Thompson wrote "cat" for the PDP-7, with "concatenate" in
mind. The cat(1) page in the v1 manual is titled, "concatenate (or
print) files". Only later did someone in Research--I don't know
who--remark on the existence of the shorter synonym. It was
deliberately adopted in v7, perhaps because it better mirrored
the command name.
But brevity is the defensible argument for "catenate", while
familiarity boosts "concatenate". It stll takes some conscious
effort for me to use the former, However, I sense sinister
vibes in "concatenate", driven by the phrase "concatenation
of events", which often is used to explain misfortune.
Doug
The florid syntax of IBM's DD was rivaled by that of GE's file utility. I
always wondered whether it was named FUTIL unwarily or with tongue in cheek.
Doug
