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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
