On Fri, Oct 31, 2008 at 01:28:02PM -0600, Scott Long wrote: > Ed Schouten wrote: >> Hello Theirry, >> >> * Thierry Herbelot <thierry.herbelot_at_free.fr> wrote: >>> with the following patch on /sbin/init, I have two different >>> behaviours depending on the console type (on a i386/32 PC) : >>> - on a video console, I see the expected two messages, >>> - on a serial console, the messages are not displayed (init silently >>> finishes its job and gets to start /etc/rc and everything) >>> >>> I assume that the writev system call is implemented in >>> src/sys/kern/tty_cons.c::cnwrite(), but I could not parse the code to >>> find an explanation. >>> >>> any taker ? >>> >>> TfH >>> >>> PS : this is initially for a RELENG_6 machine, but the code is quite >>> similar under RELENG_7 or Current >> >> Any data written to /dev/console is not multiplexed to all console >> devices, but only the first active device in the list. The reason behind >> this, is because it adds a real lot of complexity to the console code, >> especially related to polling and reading on /dev/console. >> >> This weekend I'm going to commit a replacement implementation of >> /dev/console, which also has this restriction. >> > > The multiplexed console feature is one thing that linux got right. In a > corporate setting, you really need both a serial console and a video > console in order to effectively manage the machines, as you want to be > able to access them both remotely and locally. I know this comment isn't much help, but, I am in full agreement with Scott. FreeBSD's lack of *true* multi (or even dual) console during all stages is a big disappointment to server administrators. The common reaction is: "What do you mean I can only get some messages on serial or some messages on VGA?! That's retarded!" I believe DragonFly has addressed this (offering a true dual console mechanism), and if I remember correctly, Matt Dillon discussed the code changes in great detail, citing a large amount of re-engineering required to accomplish it. > While it might be hard to build multiplexing into the console driver, > do you think it would be possible to layer a multiplexer on top of it, > similar to how the kbdmux driver works? Let's make sure that we don't implement it identically though, as there are many of us who have major problems with kbdmux (reports of LORs, and even more reports of incredibly slow keyboard input when a USB keyboard is used; workarounds are either disabling atkbd/atkbdc entirely, or disabling kbdmux entirely. In my case, I found the latter to be preferable). :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |Received on Fri Oct 31 2008 - 20:09:07 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:36 UTC