Talk:ITS Internals Manual

External docs

I had a crawl though blob/master/files (maybe the wrong place; there seem to be several different ITS filesystems on Github - was one of them a private copy I should not be linking to?), and linked all the useful internals documentation (for future readers, and as a resource for us).

Interestingly, _INFO_ and SYSDOC seem to contain a lot of duplicates, but they weren't symlinked together, as in a number of places there were slight differences, e.g. here and here.

I'm going to take a break, and come back and fill in the outline a little bit more. (I saved what you wrote to 'its-hackers', and added a bit to it; that's the start of one of the sections in the eventual thing.) Jnc (talk) 13:11, 10 September 2023 (CEST)

The "its-vault" repository holds a raw unsorted dump of files that were released from CSAIL archives during an early period of the restoration project. That is why it has many duplicates and several versions of files. From this, a curated selection is put in the main "its" repository. And sometimes bug fixes and updates are made to the "its" files, so they may not be the pristine historical data. If you can see it, it's not private. If you can find it in "its" that's the preferred location, but sometimes older versions are useful and can be linked from the "its-vault" repository. Larsbrinkhoff (talk) 08:44, 11 September 2023 (CEST)

Thanks for explaining that. I'll make sure to prefer the 'its/tree/master/src' branch. (In trying to find it, I got slightly confused by the 'its/tree/master/doc' branch, which appears to contain many of the same directories!)

In trying to clean up places where I had used 'its-vault', I discovered that 'its/tree/master/src' contains program sources, and 'its/tree/master/doc' contains documentation! Makes sense, but initially slightly confusing to those of use who were historically used to having them all thrown in together, especially as directory names are repeated in both! Although I do appreciate not having to look through AI:, MC:, etc to find what I am looking for! Jnc (talk) 06:34, 12 September 2023 (CEST)

That's right. 'doc' also contains PDFs and other documentation. In retrospect the division between ITS in-system source and documentation has not been of great value, but sometimes it's convenient to grep either doc or src for the kind of information you're after. Larsbrinkhoff (talk) 07:24, 12 September 2023 (CEST)

Off to get a nap, and hope my brain refreshes enough to do a good job out the framework. (And I have to reclaim material from Talk:Daemon too.) Jnc (talk) 05:17, 12 September 2023 (CEST)

So I started to convert external links to use, wherever possible, the its/tree/master/src|obj versions, and discovered another minor puzzle. I dutifully inserted a reference to a file in its/tree/master/doc/, and when I clicked on it, to make sure I had gotten it right, the page that turned up had been forwarded to blob/master/doc. So what is 'blob', and what is its relationship to 'tree'? (If this is some Githubism, you can see I know little of Github!) Jnc (talk) 19:59, 12 September 2023 (CEST)

That I don't know. It's a Githubism, but it might relate to how git organize its object internally. I think a 'tree' is an object that links to several other objects, i.e. like a directory. And a 'blob' stores data, e.g. a file. This isn't anything you need to know to use GitHub or git. I don't know why GitHub wants to expose this in the URL. Larsbrinkhoff (talk) 20:21, 12 September 2023 (CEST)

Random notes

FYI, the ITS repository issue tracker is full of random notes. Every program that has been added comes with an issue that usually has some notes about it, and issues are classified with various labels. There are also pure notes about random topics: https://github.com/PDP-10/its/issues?q=label%3Anote Now, this is very haphazard and often rambling, but chances are, if you search for some keywords something interesting may pop up. Larsbrinkhoff (talk) 16:50, 12 September 2023 (CEST)

I will look through them when I get a chance, to look for things to put in the outline. Jnc (talk) 17:29, 13 September 2023 (CEST)

Daemon questions

Does ATSIGN DRAGON just fork off subsidiary daemons, and then exit? I didn't see it shown on the PEEK output of a running ITS. If not, does it run in the SYS JOB?

You're right about that, I'll have to check... After all CHANNA; RAKASH programs have started, it just goes away. The most canonical dragon is "Puff the Magic Dragon" which does accounting and runs periodic programs (hourly, daily, weekly, etc). Another one is the Name Dragon, but it was historically only running on AI.

Nothing except ITS (monitor) code runs in the SYSJOB. Looks like it's exec mode too. Larsbrinkhoff (talk) 18:50, 13 September 2023 (CEST)

Speaking of which, is the latter a 'dragon'? If not, the ITS dragon/demon terminology has a hole? That's why I prefer the 'system process'/daemon terms; they are more carefully defined, with major functional differences between the two. (Demons seem to be daemons that are created on demand; while dragon and daemon seem to mean about the same thing.) And there seems to be some confusion over whether it runs in user or exec mode - or does it use both? Jnc (talk) 17:29, 13 September 2023 (CEST)

I don't think SYSJOB is a dragon because it's a job running exec mode. I avoid the term 'process' since I don't want to Unixify the ITS documentation when it already has the term 'job' which is used in the in-band documentation and source code.

Yes, it's a bit confusing that there is the 'system job' (SYSJOB), and other 'system jobs' that are normal user space jobs which are only different from having been started by the system rather than a user. I think by generic 'system job' I mean dragons + demons. (The spelling 'deamon' is used alongside 'demon' in ITS, but I think I can make a case the latter is official.) Larsbrinkhoff (talk) 18:50, 13 September 2023 (CEST)

ITS 1.4 SYSJOB

We have discussed the system job before. Here is what the 1.4 manual says (there is some more I didn't type). So far I only see the .CORE thing (labels SCOR and SCOREX) in ITS 138.

   There are various tasks ITS would like to perform, most of which
   include input-output, which would be inconvenient to implement
   directly due to the procedure originated orientation of almost all
   system routines.  Because of this a procedure was synthesized that
   is actually a part of the monitor and always runs in executive
   mode.  Known as the system job, it is scheduled [Sec 5.4] with
   lower priority than other procedures.  To aid in debugging ITS a
   feature was added to the system job so that when it had no other
   tasks to perform it would compare constant parts of ITS against a
   copy it makes initially [Sec 7.5.1].  The following are some of
   the tasks the system job performs:
   
   (1) Does .CORE's [Sec 5.3.1] for ITS to make room for more blocks
   of user variables or for the system job's copy of constant parts
   of ITS.

Larsbrinkhoff (talk) 09:30, 30 November 2023 (CEST)

Yeah, I had seen that. It makes sense that there are some things better done from inside a process, where it can wait, if needed.

But the "always runs in executive mode" brings up two questions (the first one was puzzling me before):

• There are places that talk about the SYS job running in user mode, e.g. in SYSJOB > we find the comment "DEMON JOB RUNNING IN USER MODE, WHICH THEN OUTPUTS STUFF" (I know, I should be reading the code, not comments :-) - which is it?
• If the SYS job is running in exec mode, how does the OS tell the difference between i) a system call from a process running in exec mode (legal), and a system call from inside the OS (apparently not legal)? Perhaps I'm just confused, and the second never happens, so they don't need to check for it? Or perhaps my understanding of how processes can run in exec mode is flawed?

Oh, now that things are a little calmer here, I think I have time to query COFF if there's a standard term for 'a process that only runs inside the system, and whose code is not loaded from the file system, but is built into the kernel'. Jnc (talk) 16:00, 30 November 2023 (CET)