From owner-freebsd-hackers  Wed Jan 25 09:01:34 1995
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA00974 for hackers-outgoing; Wed, 25 Jan 1995 09:01:34 -0800
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id JAA00961 for <freebsd-hackers@FreeBSD.org>; Wed, 25 Jan 1995 09:01:32 -0800
Received: by cs.weber.edu (4.1/SMI-4.1.1)
	id AA18604; Wed, 25 Jan 95 09:28:41 MST
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9501251628.AA18604@cs.weber.edu>
Subject: Re: Is this a bug?!?
To: wpaul@skynet.ctr.columbia.edu (Wankle Rotary Engine)
Date: Wed, 25 Jan 95 9:28:40 MST
Cc: bde@zeta.org.au, freebsd-hackers@FreeBSD.org
In-Reply-To: <199501250707.CAA02379@skynet.ctr.columbia.edu> from "Wankle Rotary Engine" at Jan 25, 95 02:07:01 am
X-Mailer: ELM [version 2.4dev PL52]
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

> "My lord, I have a cunning plan."
> 
> Hurm. Okay, I think I have a fix for this (conceptually at least: I
> only just now managed to wrap my brain around this whole process in a 
> satisfactory manner, and now I'm too tired to code). I think the answer
> is to stop trying to share one tty struct between what are fast becoming
> two seperate devices and instead give /dev/console a tty struct of its 
> very own. (I wonder if we should start thinking of giving it a devconf
> entry too... maybe later -- one disgusting hack at a time. :) There's a 
> small amount of nastiness in what I have in mind, but it's far better 
> than throwing in a ton of special case handling code to keep /dev/console 
> and its associated physical device from tripping over each other.

[ ... ]

> "So what do you think sirs?"

"Baldric, you wouldn't know a cunning plan if it danced on the table
 singing 'cunning plans are here again'".

8-)  8-).

Actually, this is probably close to the right way to do it; you really
want to seperate the cannonical processing module from the driver
implementation.

Sort of like 'ldterm' for streams devices.

This doesn't necessarily end with a different tty struct for each of
the drivers (this would be rather painful), but it does allow a
single device to (potentially) be output to by multiple modules (like
whatever it normally gets plus the console).

In reality, you probably want the console device to be considered as
an opener of the device:

,------------.    ,------------.
| console    |    | tty        |
`------------'    `------------'
,------------.    ,------------.
| cannonical |    | cannonical |
`------------'    `------------'
       \                /
	 \            /
	   \        /
	     \    /
	       \/
	,-------------.
	| real device |
	`-------------'

With each "real device" having the same interface for consumption by
the cannonical processing modules.

A cannonical processing module, in this case, becomes simply another
line discipline (like SLIP or PPP or DDCMP) and is divorced from the
actual device processing.


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.