[Simh] OS development

[Timothe Litt]

On 10-Jun-15 21:47, Cory Smelosky wrote:
>
> What's the copyright on the various TCP/IP stacks for TOPS-10?  I
> believe the LLNL one is public domain?
>
No idea.
> Do any of the MCOs cover the RP07 ONCE bugs in TSU04?
>
Not that I know of, but I haven't looked closely at the TOPS-20 stuff.
>>
>> So there may be different
>> branches for "last DEC release + bug fixes", "last DEC release +
>> completing unfinished or internal use but never released work" (e.g. my
>> unfinished KS10 ethernet driver), and "new features/extensions".
>>
>
> I'd make it a "user's choice" type thing - I would for personal use
> eant a rather extended version of the OSes, but for a project on the
> real hardware I'd want "last + bugfixes".
>
That's why I think we'll end up with a set of branches.  It's easy
enough to setup, but administering takes effort.

>
> Do you have any dynamic disk geometry patches?
>
No.  For the KL, they're not necessary as MSCP takes care of that.  But
that doesn't help SimH.

For the KS, it would require paravirtualization, as there are no RH11
registers that communicate geometry.  The geometries are hard-coded in
tables in the bootstrap and OS.  Since dynamic size wants to be
per-drive (per pack for removable), it's more involved than it first
appears.  The geometry and drive type register also trickles thru the OS
to things like the error log & fe filesystem creator.   And physical
backups, and RMS file placement (yes, RMS-10/20 exists), and...  Doing
it right is certainly possible, but it's not trivial.  I just define
most of my drives as RP07s...which only causes grief when restoring
backups of smaller disks with overlapping directories.  That's a problem
for me as I deal with real systems' data.  Less so for most people, who
start from scratch (and probably have less data.)

> If Stacken gives the OK I would advocate for the addition of the
> command history patches. ;)
>
We had command history in TOPS-10's last days internally, not sure if
it's in the released sources under a feature test.  If not, I can
probably find the code.
>> At this point, I think FILCOM (/O) or SOUP/SOUPR against unmodified DEC
>> sources are the best formats.  That way I don't have to deal with
>> setting up the full repo structure.
>>
>
> I'm thinking that's the best plan as well.
>
I mean this for the short term.  To a first order, if people contribute
patches, others can choose which to apply to their sources.  This
provides a distribution point that's reasonably accessible.  And I think
that's the 65% solution to the current situation of patches (good and
bad) scattered across mailing lists and private websites that come and go.

Long term, a full repo is the way to go.  I like github, but I also need
to consider their rules.  They provide free hosting for 'open source'
projects, but charge others.  TOPS itself isn't open source, but any
work we do to it would be.  So I'm not sure it's OK to put the full
source trees into a 'free' repo there...  If not, other arrangements
will be necessary.  All of which makes it a Project.  On my list, but
not near the top.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4942 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150611/815249fd/attachment-0001.bin>