Session management
Piercarlo Grandi
pcg at cs.aber.ac.uk
Tue Sep 4 03:47:56 AEST 1990
On 27 Aug 90 02:33:22 GMT, tchrist at convex.COM (Tom Christiansen) said:
tchrist> In article <8319:Aug2617:20:3690 at kramden.acf.nyu.edu>
tchrist> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
brnstnd> The difficulties with locking up tty ports are reflections of
brnstnd> two different problems: first, that ptys aren't dynamically
brnstnd> allocated in 4BSD; and second, that standard ttys exist at all.
brnstnd> Hardwired /dev/tty* should be replaced with raw /dev/modem* and
brnstnd> so on; *all* tty use should go through a common interface
brnstnd> provided by a pseudo-terminal session manager. This would solve
brnstnd> many problems at once.
Uhm. The basic problem is actually that you cannot put a line discipline
on a pipe so as to make it look like a tty line, otherwise pipes and
named pipes would be amply sufficient. Actually (named) pipes that you
can push line disciplines on and that can transfer file descriptors (the
other great idea to avoid abusing the filesystem namespace too much)
already exist, and are called streams.
Another way to get around the pipe/socket/tty incompatibility problem is
to have protocol converters among the various details of these
interfaces, and such things are part of the (unimplemented) design of
4.2BSD, under the name of wrappers.
tchrist> I think there is a crying need such a thing because the same
tchrist> code gets written again and again to do essentially the same
tchrist> thing.
I think there is acrying need for something like Accent or MUSS, where
all system objects are represented by an anonymous, opaque IPC port, and
IPC ports can be freely interchanged one with another. Too bad we don't
have that uniform interface under UNIX.
tchrist> I would make a daemon server that everyone talked to in order
tchrist> to get the session. You could instead put it in the kernel as
tchrist> a special "/dev/pty" pseudo-driver that did the allocation for
tchrist> you, but I don't see much that having it in the kernel might
tchrist> gain you considering the cost.
The fashionable thing nowadays would be to implement it as a file system
type, or maybe even an NFS filesystem server, both under BSD or System V
type systems. I am not too fond of this abuse of the filesystem notion,
but such is the trend...
--
Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk
More information about the Comp.unix.internals
mailing list