Token Ring (really- and why)

Jay West jwest at ezwind.net
Mon Apr 9 13:42:27 UTC 2012


It was written....
-------------------
>  Might it not be both more historically accurate, and a great deal  
> easier, to just use the version of FreeBSD that corresponds to  the 
> historical era being re-created?

	And skip feature, performance, and security improvements made since?
-------------------

Not in this case on the former, and the latter - agreed.

The real historical part and focus of the exhibit isn't the FreeBSD machine.
It's a dual bay HP2000 Timeshare BASIC machine. It has been restored to
pristine cosmetic and electrical running condition (2000/Access) and that's
the focus of the exhibit.

One neat feature of the HP2000, even though it was a dedicated basic
interpreter environment, it had the ability to submit jobs to HASP/MVS. MVS
could run the code and direct output back to files on the HP2000, output to
devices on that system, etc. It's a really neat add-on feature of the
display/project to include and demonstrate that functionality. Given that a
full blown VM/360 system isn't in the picture, we've used Hercules. One
issue is cobbling together some hardware glue to deal with the interface
between the HP and the "IBM", basically emulating a sync modem and 2780
device on the Hercules side. That is mostly within my skillset. The other
issue is that there needs to also be some terminal interaction on the "IBM"
side, so we have a 3174 establishment controller with some 3179 terms and a
3290 gas plasma 4-session display. The 3174 attaches to the host (Hercules)
via token ring. I had this all working perfectly with FreeBSD 7x, but when
upgrading FreeBSD we lost token ring support. I could stay on an older
version of FreeBSD, but then I am stuck with pretty old versions of Hercules
(there are problems with newer versions of Hercules compiling under older
versions of FreeBSD, some needed features are lacking in older versions of
Hercules, etc.). So now you have the gory details as to "why". Yes, there
are a few other possible ways to "skin this cat", but I have researched them
all and found various issues both subjective and objective with going those
alternate routes, hence my desire for native TR support.

So back to the topic at hand. I pulled the oltr code from 7x svn and dropped
it onto an 8x machine I had available for testing, added the requisites to
sys/conf/files.i386, and make buildkernel attempts to fly. It appears the
main reason that oltr was dropped at release 8 was that it had
IFF_NEEDSGIANT which has been deprecated for MP Safe. Additionally, some of
the functions in cpufunc.h (outbv and inbv) are no longer present in the
exact same form. Outbv and inbv I can probably easily adjust, but I'm out of
my league in the "ins & outs" of removing the need for giant locks. I
figured it wouldn't be as simple as just moving the code :) I'll beat my
head against it as time permits, thanks for any input.

Best,

J





More information about the freebsd-questions mailing list