The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Cc: tuhs@tuhs.org
Subject: [TUHS] Re: Unix v7 icheck dup problem
Date: Fri, 3 Mar 2023 14:35:37 -0500	[thread overview]
Message-ID: <CAC20D2Ow1tp4_0fjHMnEvxu_AyUmB5fGLYobJ6A-JZtT83DKcA@mail.gmail.com> (raw)
In-Reply-To: <20230303182200.B951918C08D@mercury.lcs.mit.edu>

[-- Attachment #1: Type: text/plain, Size: 3097 bytes --]

On Fri, Mar 3, 2023 at 1:22 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>     > From: KenUnix
>
>     > So is it safe to say there is no fsck or similar for v7?
>
Last fall, I recovered the original CMU sources to both. And I told Warren
after I clean things up, I'll push them to TUHS both source and binaries
but I have a number of other projects ahead of that.


>
> Yes, but that does't talk about '_end' not being defined if there
> are missing externals, either!

From V7: https://man.cat-v.org/unix_7th/1/ld     <--- this should only be a
URL - let me know if Chrome/gmail is peeing on it again

The symbols `_etext', `_edata' and `_end' (`etext', `edata'
          and `end' in C) are reserved, and if referred to, are set to
          the first location above the program, the first location
          above initialized data, and the first location above all
          data respectively.  It is erroneous to define these symbols.

Then check the section 3 man page: https://man.cat-v.org/unix_7th/3/end
which describes them in more detail.



> Interesting. I wonder how 'fcheck' made it from CMU to Bell?

The late Ted Kowaski - the primary author. Undergrad EE UMICH (Bill Joy's
roommate) and Grad EE at CMU (and my programming/lab partner originally in
Dan Sieworick's grad RT course and Gordon Bell System Architecture
courses). MTS and TSS had a disk scavenger from IBM for their common FS
[which Ted has used at MICH and I had CMU].  icheck/ncheck/dcheck seemed
less useful.
A new program was started when he was an undergrad and never finished.

It had more colorful name originally - fsck (pronounced as fisk BTW) was
finished.  I suspect the fcheck name was a USG idea.    The reason why many
of the error messages are upper case is that was the IBM convention which
both MTS and TSS used for system programs.


> I'm pretty sure the reason we liked it was not any auto-repair
> capabilities,
> but ISTR it was somewhat faster than icheck/dcheck. (Interesting that they
> were
> separate programs in V6; V5 seems to have only had check
>
CMU only ran V5 for a very short time and never in the EE Dept.  I only
knew of one system that ever ran it.  We were a hacked V6 most of the time
I was there.  V7 showed up at the end, although parts of V7 and PWB leaked
to us via different students who worked at Bell (that story was similar at
many sites).


>
> which contained the functionality of both. I wonder why they were split?
> Space?
>
Table space to support larger disk was always a huge problem. Since we
mostly ran UNIX on 11/40 class systems, it had to be able to run on non-I/D
(45 class) machines. A lot of creativity was used to keep it small.  It was
fine for RK05s and RP03s but Ted's temp space hack was done when the first
RP04-like disk showed up - it was an IBM disk on an aftermarket Unibus
controller made to look like an RP in EE and then Dan Klein and I got the
very low serial # RK07 at Mellon Institute and that was my first Unix
driver which we hacked together one weekend.
ᐧ

[-- Attachment #2: Type: text/html, Size: 6078 bytes --]

  parent reply	other threads:[~2023-03-03 19:36 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-03 18:22 Noel Chiappa
2023-03-03 19:25 ` Chet Ramey
2023-03-03 21:26   ` John Cowan
2023-03-04  0:23     ` Chet Ramey
2023-03-03 19:35 ` Clem Cole [this message]
2023-03-04  2:45   ` Jonathan Gray
2023-03-03 23:00 ` Jonathan Gray
2023-03-04  9:07 ` Jonathan Gray
2023-03-04 11:19   ` KenUnix
  -- strict thread matches above, loose matches on Subject: below --
2023-03-06  8:14 Noel Chiappa
2023-03-06  8:58 ` Jonathan Gray
2023-03-07  2:05   ` Kenneth Goodwin
2023-03-04 14:41 Noel Chiappa
2023-03-04 14:49 ` KenUnix
2023-03-02  1:59 Noel Chiappa
2023-03-02  2:11 ` Dan Cross
2023-03-02  1:36 Noel Chiappa
2023-03-02  1:56 ` John Cowan
2023-03-02  6:41   ` Lars Brinkhoff
2023-03-02  2:12 ` Bakul Shah
2023-03-02  2:46   ` Rich Salz
2023-03-01 21:29 Noel Chiappa
2023-03-01 21:54 ` KenUnix
2023-03-01 21:55 ` John Cowan
2023-03-01 22:15 ` Jon Forrest
2023-03-02  4:16 ` Jonathan Gray
2023-03-01 15:09 Noel Chiappa
2023-03-01 16:18 ` Ron Natalie
2023-03-01 16:45   ` KenUnix
2023-03-01 16:57 ` Theodore Ts'o
2023-03-01 20:52 ` Dave Horsfall
2023-03-02  1:46   ` Jonathan Gray
2023-03-02  3:05     ` Dave Horsfall
2023-03-02  7:56       ` John Cowan
2023-03-02  8:53         ` Steve Nickolas
2023-03-02  8:01       ` Jonathan Gray
2023-03-02  7:34   ` arnold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAC20D2Ow1tp4_0fjHMnEvxu_AyUmB5fGLYobJ6A-JZtT83DKcA@mail.gmail.com \
    --to=clemc@ccc.com \
    --cc=jnc@mercury.lcs.mit.edu \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).