8 Jun
2012
8 Jun
'12
3:54 a.m.
On Jun 7, 2012, at 7:10 PM, Dave McGuire wrote:
On 06/07/2012 08:23 AM, Johnny Billquist 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...?
We're just batting some ideas around. One problem is that the current
DECnet stack for Linux has fallen into dismaintenance, and if that can't
be changed, it will eventually stop working on current-ish kernels. The
idea is to write a userland (meaning outside the kernel, not running
under a non-root UID) implementation of DECnet and have non-root users'
apps (dncopy, etc) talk to it via a local socket.
That made me think of something... it could be split. If root privs are needed to get
Ethernet to do the DECnet MAC address thing (promiscuous or otherwise), one could have a
daemon that runs as root that implements the Ethernet datalink layer. Have it
communicate with a non-root daemon that does the rest of the protocol stack; that in turn
communicates with the applications.
Worth it? Perhaps not. If people aren't worried about having the whole stack in a
program with root privs, then this isn't necessary.
BTW, another thing that such an implementation should do is implement DDCMP. I looked at
it once as a module that ties into the terminal driver ("line discipline", was
that what it's called???). But in the user mode way of looking at it, a DDCMP layer
implementation would simply be a bit of plain old application code that talks to a
terminal port configured in raw mode.
paul