From owner-freebsd-hackers Tue Jan 24 23:11:09 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id XAA03746 for hackers-outgoing; Tue, 24 Jan 1995 23:11:09 -0800 Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id XAA03735 for ; Tue, 24 Jan 1995 23:11:02 -0800 Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.8/8.6.6) id CAA02379; Wed, 25 Jan 1995 02:07:04 -0500 From: Wankle Rotary Engine Message-Id: <199501250707.CAA02379@skynet.ctr.columbia.edu> Subject: Re: Is this a bug?!? To: bde@zeta.org.au (Bruce Evans) Date: Wed, 25 Jan 1995 02:07:01 -0500 (EST) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: <199501240536.QAA10618@godzilla.zeta.org.au> from "Bruce Evans" at Jan 24, 95 04:36:02 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 4687 Sender: hackers-owner@FreeBSD.org Precedence: bulk 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 ~~~~~~~~~