porr@ncrcae.Columbia.NCR.COM (Greg Porr) (10/09/90)
Does anyone know the origin of the "Multiplexed Character Special" (IFMPC) and "Multiplexed Block Special" (IFMPB) device types? These are defined in the inode.h header file as it comes in all Releases of System V, but I've never seen it used in any kernel source. Greg Porr
cowan@marob.masa.com (John Cowan) (10/10/90)
In article <6633@ncrcae.Columbia.NCR.COM> porr@ncrcae.Columbia.NCR.COM (Greg Porr) writes: > >Does anyone know the origin of the "Multiplexed Character Special" (IFMPC) >and "Multiplexed Block Special" (IFMPB) device types? These are defined >in the inode.h header file as it comes in all Releases of System V, but >I've never seen it used in any kernel source. > > >Greg Porr Multiplexed devices were an unlovely hack in straight V7 that didn't make it into either BSD or Sys V flavors of *ix. They essentially tried to handle the "many to one, multiple connections" problem. They predate named pipes, sockets, etc. -- cowan@marob.masa.com (aka ...!hombre!marob!cowan) e'osai ko sarji la lojban
guy@auspex.auspex.com (Guy Harris) (10/10/90)
>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. I think they were rather buggy. I also think Berkeley fixed some of the bugs in 4.1BSD, and used them for some IPC stuff (did "comsat" use them?), but nuked them in 4.2BSD in favor of sockets. >These are defined in the inode.h header file as it comes in all Releases >of System V, but I've never seen it used in any kernel source. It's somewhat amusing that the #defines survive in S5.
smb@ulysses.att.com (Steven Bellovin) (10/11/90)
As several people have noted, multiplexor devices date to v7. They were indeed quite buggy, though I know of a few uses for the 4.1bsd versions. The early BSD support for BLIT terminals (the ancestor of the 5620 and the 630) was based on them, as was the IPC mechanism for a multi-player adventure-style game called t4c. The driver had a lot of potential if only (a) it were better-documented, and (b) it worked...
chris@mimsy.umd.edu (Chris Torek) (10/11/90)
In article <13869@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes: >As several people have noted, multiplexor devices date to v7. They were >indeed quite buggy, though I know of a few uses for the 4.1bsd versions. >The early BSD support for BLIT terminals .... Let us not forget Gosling Emacs. :-) >The driver had a lot of potential if only (a) it were better-documented, >and (b) it worked... The 4.1BSD version had two major bugs: 1) A race condition occasionally resulted in trashed file systems. Easily fixed, but quite a problem. 2) Tty channels could not be properly disconnected and reconnected. I forget exactly how this worked (or failed). After fixing both of these, we used multiplexed files quite happily for some years. My version of Gosmacs still supports them (theoretically). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
jfh@rpp386.cactus.org (John F. Haugh II) (10/11/90)
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
tif@doorstop.austin.ibm.com (Paul Chamberlain) (10/11/90)
In article <6633@ncrcae.Columbia.NCR.COM> porr@ncrcae.Columbia.NCR.COM (Greg Porr) writes: >Does anyone know the origin of the "Multiplexed Character Special" (IFMPC) >and "Multiplexed Block Special" (IFMPB) device types? My RT has a comment in inode.h that these are "obsolete," however, the console (hft) device is a multiplexed character device. Are these the same? Paul Chamberlain | I do NOT represent IBM. tif@doorstop, sc30661 at ausvm6 512/838-7008 | ...!cs.utexas.edu!ibmaus!auschs!doorstop.austin.ibm.com!tif
friedl@mtndew.Tustin.CA.US (Steve Friedl) (10/13/90)
Steven Bellovin: > As several people have noted, multiplexor devices date to v7. They were > indeed quite buggy, though I know of a few uses for the 4.1bsd versions. > The early BSD support for BLIT terminals (the ancestor of the 5620 and > the 630) was based on them, as was the IPC mechanism for a multi-player > adventure-style game called t4c. Gosling Emacs supported mpx files as well. We had no end of problems with them when I was working on it back at Kent State, but later found out that this was probably due to mpx bugs in the kernel. I think that Chris Torek had patches to fix them... Steve -- Stephen J. Friedl, KA8CMY / I speak for me only / Tustin, CA / 3B2-kind-of-guy +1 714 544 6561 / friedl@mtndew.Tustin.CA.US / {uunet,attmail}!mtndew!friedl "No job is too big, no fee is too big" - Gary W. Keefe
plona@remus.rutgers.edu (Lawrence Plona) (10/13/90)
The folowing is mpx(2) from volume one of the UNIX programmer's manual
(version 7). Ritchie's STREAMS has replaced this and other multiplexing
facilities with a more flexible and well thought out system.
- Larry Plona
------------------------------------------------------------
NAME
mpx - create and manipulate multiplexed files
SYNOPSIS
mpx( name, access )
char *name;
join( fd, xd )
chan( xd )
extract( i, xd )
attach( i, xd )
detach( i, xd )
connect( fd, cd, end )
npgrp( i, xd, pgrp )
ckill( i, xd, signal )
#include<sys/mx.h>
mpxcall( cmd, vec )
int *vec;
DESCRIPTION
mpxcall( cmd, vec ) is the system call shared by the library
routines described below. cmd selects a commend using values defined
in <sys/mx.h>. vec is the address of a structure containing the
arguments for the command.
mpx( name, access )
mpx creates and opens the file name with access permission access
(see creat(2)) and returns a file descriptor available for reading
and writing. A -1 is returned if the file cannot be created, if name
already exists, or if the file table or other operating system data
structures are full. The file descriptor is required for use with
other routines.
If name designates a null string, a file descriptor is returned as
described but no entry is created in the file system.
Once created, an mpx file may be opened (see open(2)) by any process.
This provides a form of interprocess communication whereby a process
B can 'call' process A by opening an mpx file created by A. To B, the
file is ordinary with one exception: the connect promitive could be
applied to it. Otherwise the functions described below are used only
in process A and descendants that inherit the open mpx file.
When a process opens an mpx file, the owner of the file receives a
control message when the file is next read. The method for
'answering' this kind of call involves using attach and detach as
described in more detail below.
Once B has opened A's mpx file it is said to have a channel to A. A
channel is a pair of data streams: in this case, one from B to A and
the other from A to B. Several processes may open the same mpx file
yielding multiple channels within the one mpx file. By accessing the
appropriate channel, A can communicate with B and any others. When A
reads (see read(2)) from the mpx file data written to A by the other
processes appears in A's buffer using a record format described in
mpxio(5). When A writes (see write(2)) on its mpx file the data must
be formatted in a similar way.
The following commands are used to manipulate mpx files and channels.
join - adds a new channel on an mpx file to an open file F. I/O on
the new channel is I/O on F.
chan - creates a new channel.
extract - file descripter maintenance.
connect - similar to join except that the open file F is connected
to an existing channel.
attach, detach - used with call protocol.
npgrp - manipulates process group numbers so that a channel can
act as a control terminal (see tty(4)).
ckill - send signal (see signal(2)) to process group through
channel.
A maximum of 15 channels may be connected to an mpx file. They are
numbered 0 through 14. join may be used to make one mpx file appear
as a channel on another mpx file. A hierarchy or tree of mpx files
may be set up in this way. In this case one of the mpx files must be
the root of a tree where the other mpx files are interior nodes. The
maximum depth of such a tree is 4.
------
relentless implementation details deleted.
------
FILES
/usr/include/sys/mx.h
/usr/include/sgtty.h
SEE ALSO
mpxio(5)
BUGS
mpx files are an experimental part of the operating system more
subject to change and prone to bugs than other parts. Maintenance
programs, e.g. icheck(1), diagnose mpx files as an illegal mode.
Channels may only be connected to objects in the operating system
that are accessible through the line discipline mechanism. Higher
performance line disciplines are needed. The maximum tree depth
restriction is not really checked. A non destructive disconnect
primitive (inverse of connect) is not provided. A non blocking flow
control strategy based on messages defined in mpxio(5) should not be
attempted by novices; the enabling ioctl commend should be protected.
The join operation could be subsumed by connect. A mechanism is
needed for moving a channel from one location in an mpx tree to
another.guy@auspex.auspex.com (Guy Harris) (10/13/90)
>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. That's a clone device, not a V7-style multiplexed character device; the latter is what was being asked about.
mwp@ubeaut.oz.au (Michael Paddon) (10/19/90)
From article <6633@ncrcae.Columbia.NCR.COM>, by porr@ncrcae.Columbia.NCR.COM (Greg Porr): > > Does anyone know the origin of the "Multiplexed Character Special" (IFMPC) > and "Multiplexed Block Special" (IFMPB) device types? These are defined > in the inode.h header file as it comes in all Releases of System V, but > I've never seen it used in any kernel source. There used to be multiplexed files in 7th Edition. From memory, these were basically named pipes with multiple 'channels'. Michael ------------------------------------------------------------------- | | Internet: paddon@meo78b.enet.dec.com | | | ACSnet: mwp@ubeaut.oz.au | | Michael Paddon | ACSnet: mwp@munnari.oz.au | | | EasyNet: meo78b::paddon | | | Voice: +61 3 895 9392 | -------------------------------------------------------------------