Consoles, past and future.

[Tom Rhodes]

On Fri, 02 Sep 2005 09:39:19 +0200
Poul-Henning Kamp <phk at haven.freebsd.dk> wrote:

[SNIP]

> Nobody mandates that 2 & 3 has to happen on "/dev/console", /sbin/init
> could open any device it prefer for this, so if the device drivers
> export a proposed device name along with their console functions,
> /sbin/init could pick this up with a sysctl and proceed from there.
> The loader could present a hint to override this.
> 
> That leaves us with 4 and 5, which we can't do much about because
> short-sighted UNIX standards which goldpated the past rather than
> steer the future and therefore mandate that /dev/console must be a
> tty(4) device.
> 
> But we can implement /dev/console as a pseudo device driver without
> breaking anything.
> 
> Most people these days view this part of the console functionality
> through syslog or xconsole(-like) programs anyway which uses various
> ioctls to get their bit of the cake.
> 
> In order to stay compatible with old stuff, we could use a null-modem
> backside device so that people could say "tip console" and interact
> with dump(8) that way.  (Keeping a buffer of the most recent 2K output
> and replaying that on open would probably be a good idea).
> 
> The driver would also have the task of directing the output to
> /dev/console to syslogd for permanent recording.
> 
> Thanks for listening.
> 

You're welcome.  :)

My question is, and I know this hasn't been tested so be my
guest and theorize a bit.  Are there any performance gains
or losses as a result of taking this route?

-- 
Tom Rhodes