2 Aug
2022
2 Aug
'22
10:38 p.m.
Agreed. The interesting possibility is an API library that is sufficiently close to the
Linux API that applications can work with just a recompile. I don't know if
that's doable; I haven't looked at the Linux API in decades.
For that matter, there's also the DEC Unix API, about which I'm equally ignorant.
Obviously, another possibility would be for someone else to do what I just described. The
PyDECnet API (in T1.1) is I think pretty straightforward and easy to use; roughly speaking
it does what the Session Control spec says a generic API would look like. The
communication mechanism to the running DECnet code is a Unix domain streaming mode
connection carrying JSON encoded requests and responses, full duplex both ways.
That's what the Python API wrappers talk to. Those wrappers are simple and so is
using them; in T1.1 there are several applications (PMR, NFT) that show this.
paul
On Aug 2, 2022, at 4:29 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
I would suspect the only applications that exist, and people still see, are all the
standard DECnet utilities. But that's a whole bunch of programs, so it would be quite
an effort to rewrite all of it to use some other API.
Johnny
On 2022-08-02 17:25, Brian Angus wrote:
I like that idea, although I do wonder how many
"real" applications would really need, want, or even try to support DECnet
directly in these modern times? For the terminal server case that I am initially
interested in building, CTERM and a few network diagnostic tools would keep me very
satisfied, Adding in some file transfer capabilities would be simply awesome.
It would be really useful even if some of these functions were only exposed through
internal PyDECnet sub-commands instead of being available system-wide. I've been
happily using PyDECnet for a couple of years, but I haven't yet upgraded to your new
test releases, and I haven't kept up on what all is included in your future plans?
Regardless, I suspect that any somewhat easier way to keep a version of DECnet running on
Linux with even the minimal set of tools would be appreciated by many around here. How do
you think the performance would be with CTERM written in Python?
On Tue, Aug 2, 2022 at 10:46 AM Paul Koning <paulkoning(a)comcast.net
<mailto:paulkoning@comcast.net>> wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se On Aug 2, 2022, at 10:40 AM, Brian Angus
<brian.angus(a)gmail.com
<mailto:brian.angus@gmail.com>> wrote:
Hello,
I'm not a programmer, at least not a very good one, and I'm quite
happy
to expose my ignorance in the effort to learn something new,
so I was wondering how real this dependency is on having Linux
kernel support for DECnet. We are quite able to put DECnet packets
out on the wire using various user mode processes such as with our
favourite emulator SimH. I currently run VAX DECnet on several
linux boxes without any special or unusual kernel shenanigans using
a simple TAP ethernet driver. I also use other non-IP based
protocols such as LAT that do not require any special kernel mode
modules, drivers or privileges.
Wouldn't it be awesome if we could install a "simple" DECnet
daemon on Linux and tweak the few user mode commands that we still
use to point to that instead of the special kernel drivers that are
needed today. This is probably just wishful thinking, but a very
simple non-kernel DECnet implementation might help ensure its
survival for a few more decades.
I could well be completely wrong, but I thought I would ask anyway.
What kernel
support gives you is the ability to use the standard
"socket" kernel API to communicate using DECnet. User mode code
means a different API.
Now if Linux were to add a way to create a user-mode back end to
sockets, sort of like a socket analog to FUSE (file system in user
mode), then you could do DECnet in user mode and still get sockets.
Hm... SUSE? (Oh well, that acronym is taken...)
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se>
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se