Token Ring (really- and why)
freebsd-questions at herveybayaustralia.com.au
Mon Apr 9 14:02:34 UTC 2012
On 04/09/12 23:42, Jay West wrote:
> 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.
I've been following this thread with a kind of bizarre fascination (or
more accurately perhaps it should be the fascination of the bizarre?).
Perhaps you should put those questions to the hackers@ list? Or even net@?
Where is this exhibit? Is there somewhere I can follow your progress
with this interesting diorama? I'd be fascinated to see this in operation :)
More information about the freebsd-questions