Date: Wed, 25 Jan 1995 02:07:01 -0500 (EST) From: Wankle Rotary Engine <wpaul@skynet.ctr.columbia.edu> To: bde@zeta.org.au (Bruce Evans) Cc: freebsd-hackers@FreeBSD.org Subject: Re: Is this a bug?!? Message-ID: <199501250707.CAA02379@skynet.ctr.columbia.edu> In-Reply-To: <199501240536.QAA10618@godzilla.zeta.org.au> from "Bruce Evans" at Jan 24, 95 04:36:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
They say this Bruce Evans person was kidding when he wrote:
>
> >that writing to /dev/ttyv0 actually causes the kernel to go from
> >write(), to vn_write(), to ffsspec_write(), to spec_write(), to cn_write(),
> >to scwrite(), to ttwrite() and then to b_to_q() and a panic. The
>
> This layering seems excessive.
A man after my own heart! This isn't the end of the line either. Normally
(without panics) ttwrite() would eventually get to putc(), which would then
find its way back to syscons and scput(). It looks to me though that
there's no way to improve on this without changing a huge number of
related things.
> 0/0 is correct for the console. It gets translated to 12/0 in cons.c.
> The current version of syscons, and all versions of sio, cannot tell
> if they are working with the 0/0 device, and this causes problems when
> the 12/0 device is closed while the 0/0 device is open or vice versa.
> I fixed this, but now the process group info for the 12/0 device doesn't
> go away when the 12/0 device is closed, and TIOCSTTY fails in login_tty().
>
> Bruce
"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.
First off, I like the idea of wedging cn{open, close}() in between
spec_{open, close}() and sc{open,close}(). But I think that having
cnopen() 'lie' to the underlying device driver is a Bad Thing: it always
passes 12/0 to scopen() as a device value, which means that there's no
way for syscons to know if it's dealing with /dev/ttyv0 or /dev/console.
Yes, I know this would mean tying different device drivers together
in a disgusting way, but cons.c can't handle this by itself. What I
propose is this:
- Have cons.c declare a tty struct for itself (thus eating up a small
chunk of memory. oh well).
- Pass the real device value to the underlying driver. (0/0, 12/0 or 28/0,
depending on the circumstances)
- Let scopen() (and sioopen()) test the value of 'dev' that's passed to
it: if it's given a device with a major value of 0, then it knows that
it's being asked to handle the console, and it can point 'tp' at the
console's tty struct instead of one of its own array of tty structs.
If major(dev) isn't 0, then go about business as usual.
- Implement similar hackery for scclose() (and sioclose()).
I think this would prevent the process group info straight (you'd no
longer have to worry about the two different open and close calls
clobbering each other since you'd have two independent sets of
data -- I don't see an immediate problem with this, but then again I'm
also half asleep). If done right, it should also allow for the correct
t_dev value to show up in the process table, which would solve the
problem of 'w' not working right when using /dev/console as a real live
login device. This in turn would allow me to implement my Master Plan (tm),
which is to actually have people *use* /dev/console as a login device.
(Call me crazy, but "Last login on console" just looks cooler than "Last
login on ttyv0.") Finally, this would keep all the changes isloated to
the i386-specific code, which is a pretty good idea since this is
largely an i386-specific bug. :)
I can see only one problem with all this: it would break PCVT, though
hopefully not so badly that the PCVT author would be seized with an
irresistable urge to hunt me down and force me to watch Highlander II
until my eyes bleed.
Tomorrow I'll take a whack at this to see if it'll actually work.
"So what do you think sirs?"
-Bill
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~T~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Bill Paul (212) 854-6020 | System Manager
Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research
Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Møøse Illuminati: ignore it and be confused, or join it and be confusing!
~~~~~~~~ FreeBSD 2.1.0-Development #1: Fri Jan 20 14:28:17 EST 1995 ~~~~~~~~~
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501250707.CAA02379>