Date: Wed, 13 Mar 1996 08:42:50 +0100 (MET) From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: COMCONSOLE: a patch and a problem Message-ID: <199603130742.IAA10415@uriah.heep.sax.de> In-Reply-To: <199603130044.QAA07753@cozumel.tcs.com> from "Douglas Ambrisko" at Mar 12, 96 04:44:24 pm
next in thread | previous in thread | raw e-mail | index | archive | help
As Douglas Ambrisko wrote: > | syscons uses a different tty structure for the console than for VT1. > > I guess my question is why? Syscons originally shared the struct tty between the console and ttyv0, but tried to work around problems in the generic console code by using a different struct tty for it. Many of the problems with the generic console code have been fixed now (have a look at the CVS log of sys/i386/i386/cons.[ch] to see what happened), but syscons' hack^H^H^H^Hworkaround remains. > issue here is that we can't really have a getty on com1 and ttyv0 since this > would upset a mouse on com1. I feel if we can't do this then we The problems with running getty on /dev/console were related to things like properly handling the tty-level open()/close() of the associated devices. You normally don't notice the problems since syslogd holds /dev/console open all the time, except once during /etc/daily, where it is being restarted. The effect was that you came back to the machine next morning, and haven't seen any output on the console when logging in. > Also it is important that part of the structure for the serial console > and graphics console is different or flagged so the graphics ioctl check > will fail to detect whether or not the console is a serial port or graphics > console. This code is used in sysinstall. You can simply issue an ioctl(VT_GETACTIVE) to the stdin file descriptor. It is implemented in both, syscons and pcvt (though the latter is not that important for sysinstall). If the ioctl succeeds, you're usign a graphics console, otherwise it's either a serial or no console at all. > Yep that's why I suggested to save the boot mode in the kernel like what > happens when you boot -c and modify the kernel. Right now I don't know > what would be involved to do that. Well, dset(8) is rather a (appreciated) hack. It writes back to the /kernel file. This is, however, too late for the boot -h flag, since this must already be evaluated by the boot code before any kernel file is known or could be read. It's not even necessary that there's a FreeBSD file system structure around on the boot medium. For example, the system might not yet be installed, or one might create a floppy containing just the bootstrap only, and wants to enter ``7:sd(4,a)/kernel'' at the boot prompt since he doesn't want to use booteasy for boot selection. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603130742.IAA10415>