Date: Wed, 25 Jan 95 9:28:40 MST From: terry@cs.weber.edu (Terry Lambert) To: wpaul@skynet.ctr.columbia.edu (Wankle Rotary Engine) Cc: bde@zeta.org.au, freebsd-hackers@FreeBSD.org Subject: Re: Is this a bug?!? Message-ID: <9501251628.AA18604@cs.weber.edu> In-Reply-To: <199501250707.CAA02379@skynet.ctr.columbia.edu> from "Wankle Rotary Engine" at Jan 25, 95 02:07:01 am
next in thread | previous in thread | raw e-mail | index | archive | help
> "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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9501251628.AA18604>