Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!rpi!batcomputer!munnari.oz.au!metro!cluster!necisa!boyd
From: boyd@necisa.ho.necisa.oz (Boyd Roberts)
Newsgroups: comp.unix.wizards
Subject: Re: Session management
Keywords: pty login daemon session
Message-ID: <1843@necisa.ho.necisa.oz>
Date: 28 Aug 90 06:39:02 GMT
References: <6038@muffin.cme.nist.gov> <3954@auspex.auspex.com> <8319:Aug2617:20:3690@kramden.acf.nyu.edu> <105387@convex.convex.com>
Organization: NEC Information Systems Australia Pty. Ltd.
Lines: 33

In article <105387@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes:
>
>I would make a daemon server that everyone talked to in order to get
>the session.  You could instead put it in the kernel as a special 
>"/dev/pty" pseudo-driver that did the allocation for you, but I don't
>see much that having it in the kernel might gain you considering
>the cost.
>

You can do this stuff with a `mounted process', the connection line
discipline (conn_ld) and the message line discipline (mesg_ld) with V8/9/10.

When "/dev/service" is opened your user mode process gets a message
that something is requesting an open (via select() and read()) and you
then pass a file descriptor back across the stream (with the
right line discplines pushed) that refers to "/dev/serviceXX".

Your process, mounted on "/dev/service", manages a table of
"/dev/serviceXX" for some XX.  And, of course, you can deny the
service as well.  The message you get tells you who's on the
far end of the open -- but it's fairly UNIX specific  (uid, gid,
login name and process nice value -- from memory).

I think its a lot simpler with the V9 ipc library, but I don't have
my V9 manual to hand.  But the library hides some of the
intricacies of the implementation.   It's nice.

Hume will followup and catch me out -- just watch...


Boyd Roberts			boyd@necisa.ho.necisa.oz.au

``When the going gets wierd, the weird turn pro...''