On 7 Jun 2012, at 13:32, Johnny Billquist <bqt at softjar.se> wrote:
Are you actually talking now about implementing a DECnet stack on a machine in user mode?
That is definitely not doable. You need atleast one part that talks raw ethernet, if you want access to the local ethernet.
No. What we are trying to work out is if (as it seems to be) it is
possible to implement a functional DECnet stack without having to
directly alterbthe kernel code (as is currently required) because
doing so limits portability and compatibility due to ever-shifting
sands of Linux kernel development.
And that part needs to run as root. No way around that.
We established that, yes. That's where my idea of using pcap and
running the interface in promicuous mode came out of.
Normal user programs should of course not need to be running as root, nor much around in the kernel, but there is nothing tricky about this. The DECnet stack is one process. Any other program talking DECnet needs to talk to the DECnet stack. That can be done in a number of ways. Unix sockets, TCP/IP sockets, shared memory, named pipes... Just pick something.
So with the daemon running as root it is possible to access it from
'userland' without root access. Excellent.
The ugly part is that you'll need to write all the software to handle all the protocols that sits on top of DECnet, such as a FAL listener, a FAL user client, CTERM listener and client, NICE, PHONE, MAIL... The list goes on...
You'll probably want to write a library with all the DECnet library primitives so that you have a nice API for the user level code to use. If you are lucky, the API in the current implementation can be adapted to your new implementation, which will make it possible to reuse a lot of code. I have not looked at how the current DECnet API looks like in Linux.
That seems like a sound idea to me. If the code already exists there's
no point on duplicating the effort unless it's required.
Anyway, this is a different story than any potential problems with promiscuous mode...
As I explained, my thinking was to use promiscuous mode to created a
DECnet stack that wasn't kernel dependant. That's where Dave and I got
hung up on potential small issues.
All clear there now, we can move on!
And you still need to be root to play with ethernet.
Indeed.
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
A vaxstation 2000 and a microvax 2000 run V4.7 too. With VWS instead of Motif at a reasonable speed.
Hans
-----Original Message-----
From: Dave McGuire <mcguire at neurotica.com>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 07 Jun 2012 07:46:10
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Introducing myself... and my little network
On 06/07/2012 07:26 AM, Jordi Guillaumes i Pons wrote:
According to this:
http://h71000.www7.hp.com/openvms/os/openvms-release-history.html
Support for the 4000/90 came in version 5.5-2 (1992). The 3300 was
supported in 5.0-2 and the 4000 mod. 2000 in 5.4-2. So none of my real
boxen can run 4.7.
Well you've gotta find yourself some more machines! 11/750s are
probably the most common of the 4.x-capable machines, though there don't
seem to be many left floating around.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
The Vaxstation 4000 model 60 is rated at approx 20 VUPS, the 90A at 40 VUPS. I don"t own a model 90. The 90A's are very fast compared to other Vaxes I worked with. Two exceptions, the 4705A and the 4108 (4105?, the one that cames in a plastic PC style cabinet) were also quite fast. The Vaxstation 4000 model 96 is faster than the 90A (45 VUPS). I certainly would like one for my collection!
Hans
------Origineel bericht------
Van: Mark Benson
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Introducing myself... and my little network
Verzonden: 7 juni 2012 13:41
On 7 Jun 2012, at 10:33, Jordi Guillaumes i Pons
<jg at jordi.guillaumes.name> wrote:
Hello list,
I've just joined HECnet under the area 7, and I wanted to introduce myself and my little puppies :)
Hello!
I am interested to know how you find the performance of the VAXstation
4000/60 compared to others.
Good to see someone with such great skills on old iron join us. I know
very little outside vasics and simple DECnet setup :)
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa
El 07/06/2012, a les 14:23, Johnny Billquist <bqt at softjar.se> va escriure:
On 2012-06-07 12:42, Dave McGuire wrote:
On 06/07/2012 06:37 AM, Sampsa Laine wrote:
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a
socket?
Cool idea - you could even have multiple hosts connect this way but
export one DECNET endpoint, i.e. run CTERM on Box A whilst FAL goes
to Box B, and MAIL to Box C :)
Yes, you could multiplex/demultiplex it any way you wanted. It would
open up all sorts of interesting configuration possibilities.
I think it would help if you actually explained a little more what you actually want to accomplish, and what you see as the problems...?
If I've understood it correctly, the idea is to replace the (dying) kernel support for DECNet under linux by userland code, so it the current module dies definitely due to kernel ABI changes we could still use decnet in the Linux boxes.
The process separation and distributed tasks are just a proposed improvement over the initial idea.
I'd add as an additional benefit that moving decnet out of the kernel would make possible to port it to other unix flavours, like the BSDs and Mac OSX.
Johnny
Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa
El 07/06/2012, a les 13:46, Dave McGuire <mcguire at neurotica.com> va escriure:
On 06/07/2012 07:26 AM, Jordi Guillaumes i Pons wrote:
According to this:
http://h71000.www7.hp.com/openvms/os/openvms-release-history.html
Support for the 4000/90 came in version 5.5-2 (1992). The 3300 was
supported in 5.0-2 and the 4000 mod. 2000 in 5.4-2. So none of my real
boxen can run 4.7.
Well you've gotta find yourself some more machines! 11/750s are
probably the most common of the 4.x-capable machines, though there don't
seem to be many left floating around.
Heh, then I would have to find also a new home and probably an attorney to handle de divorce demand ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 2012-06-07 14:22, Johnny Billquist wrote:
On 2012-06-07 12:37, Sampsa Laine wrote:
On 7 Jun 2012, at 11:29, Dave McGuire wrote:
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a socket?
Cool idea - you could even have multiple hosts connect this way but
export one DECNET endpoint, i.e. run CTERM on Box A whilst FAL goes to
Box B, and MAIL to Box C :)
Are you trying to suggest something like NAT for DECnet?
I'm not sure how easy that would be to do in DECnet, as it works in some
different ways than IP that might cause problems doing this.
Reading through things a little more...
Are you actually talking now about implementing a DECnet stack on a machine in user mode?
That is definitely not doable. You need atleast one part that talks raw ethernet, if you want access to the local ethernet. And that part needs to run as root. No way around that.
Normal user programs should of course not need to be running as root, nor much around in the kernel, but there is nothing tricky about this. The DECnet stack is one process. Any other program talking DECnet needs to talk to the DECnet stack. That can be done in a number of ways. Unix sockets, TCP/IP sockets, shared memory, named pipes... Just pick something.
The ugly part is that you'll need to write all the software to handle all the protocols that sits on top of DECnet, such as a FAL listener, a FAL user client, CTERM listener and client, NICE, PHONE, MAIL... The list goes on...
You'll probably want to write a library with all the DECnet library primitives so that you have a nice API for the user level code to use. If you are lucky, the API in the current implementation can be adapted to your new implementation, which will make it possible to reuse a lot of code. I have not looked at how the current DECnet API looks like in Linux.
Anyway, this is a different story than any potential problems with promiscuous mode...
And you still need to be root to play with ethernet.
Johnny
It's worth stating that both Sampsa and I (at least) have a good deal of software sitting on our servers for VAXen running VMS.
My AlphaServer is still up and down at the moment as local usage dictates. I still need to get round to that squid cache...
Mark.
Sent from my iPad
On 7 Jun 2012, at 11:48, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote:
Al 07/06/12 12:11, En/na hvlems at zonnet.nl ha escrit:
Jordi,
You wrote that the NIC on the 4000-90 was broken. Did you try an external transceiver on the AUI connector (there's a switch on the back).
An Alllied Telesys or DEC transceiver might solve the issue. The logic that drives the BNC connector is on a separate module IIRC.
I didn't. Actually, I thought you needed a thickwire segment to use a transceiver and a drop cable. I should have researched it better. Any idea of the DEC name for that thinwire transceiver? (Or a compabtible one). Anyways, I think I canibalized that machine a little bit, so I'm not sure what is actually inside of the inclosure. It looks like a nice summer vacation project :)
If you need software kits for the VAX, post your needs. If I have the kit(s) I'll burn them on a CD. Hans
Oh, thanks. As I said, I've plenty of "modern" stuff, but I miss some of the older software I used back in those days (pre-5.0), a (call it nostalgia) I'm quite trying to reproduce that first environment I worked on. Right now, I miss:
- FMS
- TDMS
- VAX BASIC
- LSE
That's pretty all. I also used AI1 (the dreaded office package) but I'm not sure I'll want to fight that monster again ;). No need to burn a CD, we could arrange the transfer by network (HECnet or regular internet). I understand the use of that stuff is covered by the hobbyist license (not sure about TDMS though), so we would not do anything out of the law.
On 2012-06-07 12:42, Dave McGuire wrote:
On 06/07/2012 06:37 AM, Sampsa Laine wrote:
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a
socket?
Cool idea - you could even have multiple hosts connect this way but
export one DECNET endpoint, i.e. run CTERM on Box A whilst FAL goes
to Box B, and MAIL to Box C :)
Yes, you could multiplex/demultiplex it any way you wanted. It would
open up all sorts of interesting configuration possibilities.
I think it would help if you actually explained a little more what you actually want to accomplish, and what you see as the problems...?
Johnny
Mark,
I've run a 4000/60 and 4000/90 at different times.
The '60s are about 12 VPUs and the '90s are about 40 VPUs. However, both numbers are quite respectable and I've found that having a reasonable amount of memory (64MB+) enables both to be quite competent. Expect to wait about 3 times as long for CPU intensive tasks to complete on the '60.
Most of time however you don't really notice much difference.
Regards, Mark.
Sent from my iPad
On 7 Jun 2012, at 12:41, Mark Benson <md.benson at gmail.com> wrote:
On 7 Jun 2012, at 10:33, Jordi Guillaumes i Pons
<jg at jordi.guillaumes.name> wrote:
Hello list,
I've just joined HECnet under the area 7, and I wanted to introduce myself and my little puppies :)
Hello!
I am interested to know how you find the performance of the VAXstation
4000/60 compared to others.
Good to see someone with such great skills on old iron join us. I know
very little outside vasics and simple DECnet setup :)
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
On 2012-06-07 12:37, Sampsa Laine wrote:
On 7 Jun 2012, at 11:29, Dave McGuire wrote:
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a socket?
Cool idea - you could even have multiple hosts connect this way but export one DECNET endpoint, i.e. run CTERM on Box A whilst FAL goes to Box B, and MAIL to Box C :)
Are you trying to suggest something like NAT for DECnet?
I'm not sure how easy that would be to do in DECnet, as it works in some different ways than IP that might cause problems doing this.
Johnny
