Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.unix.internals
Subject: Re: Multiplexed Special Devices
Message-ID: <18584@rpp386.cactus.org>
Date: 11 Oct 90 04:05:02 GMT
References: <6633@ncrcae.Columbia.NCR.COM> <4171@auspex.auspex.com>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 26
X-Clever-Slogan: Recycle or Die.

In article <4171@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>Does anyone know the origin of the "Multiplexed Character Special" (IFMPC)
>>and "Multiplexed Block Special" (IFMPB) device types?
>
>It comes from "The UNIX Time-Sharing System, Seventh Edition" - more
>commonly known as "V7".  I don't remember any "multiplexed block
>special" files being supported, but the multiplexed character special
>files were a sort of IPC mechanism.  You'll have to find somebody who
>still has a V7 manual handy in order to get a full description; look
>for, as I remember, the "mpx" man page.

IBM has them in AIX v3.1 as multiplexed character devices.  each
open returns a different channel.  Thus, the PTY device driver is
a multiplexed character device.  When you want a PTY pair you open
/dev/pts and see what you got.  Then you open the /dev/ptc that
matches, and you have a PTY all to yourself.  The HFT device driver
works this way as well - when you want a new virtual native display
you just open /dev/hft, and poof, instant channel.

I've seen references in old V7 and such manuals about multiplexed
pipes.  I can't imagine what one of those must have smelled like.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
"SCCS, the source motel!  Programs check in and never check out!"
		-- Ken Thompson