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)