Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #8285

Re: Use of a virtual console

Show all headers | View raw

On Fri, 03 Jul 2015 05:17:05 -0400, James Harris
<james.harris.1@gmail.com> wrote:

> Something Rod said

It's Friday there, right?  Yeah, blame Rod for this ... lol.

> Something [...] in the thread "remote OS install and boot issues for
> test PCs" prompted this suggestion/query. I'd be interested to hear what
> you think of it. Should an OS have/model an old-fashioned text-mode
> console, especially at startup? Explanation follows.

I love DOS' CLI.  Linux is useless without "Terminal" for X-Windows, or
perhaps xterm.  You have to have getty (agetty, mingetty etc) and
sh (bash, csh) shell to recover from any Linux problem, i.e., you need
a non-gui boot login for Linux recovery.  And, GRUB needs command line
to tweak until Linux is correctly configured.  Windows 98/SE uses a DOS
console for DOS apps.  Even current Windows versions still need the
ubiquitous command.com any time Windows has a problem, e.g., resetting
networking or DNS, deleting virii, fixing long filenames, finding files
quickly, etc.  So, is that even the right question?  Given that none of
these OSes can seem to eliminate use of a terminal, I would wonder if
it's even "possible" to implement an OS without having a CLI or terminal
console available somewhere.  And, just what do you do if the GUI boot
process can't find a known graphics video mode? ...

> First, the term. I think of a "console" as a very simple terminal which
> displays output in a line-by-line form, i.e. has no cursor controls to
> go back to previous lines, and it allows an operator to enter commands.

I would agree, but Linux seems to divide this into two: getty, sh,
or perhaps I conflate the two.

> We are generally used to bare-metal development on a PC for which we
> interact with keyboard and screen by using the BIOS or direct port IO
> or direct memory updates. But those won't work remotely.

Keyboard won't?  I thought you could stuff the BIOS keyboard buffer.
Isn't that how DOS macro TSRs work?

Off hand, I don't recall a BIOS buffer for the mouse ...

The screen is directly readable or writable by any software, e.g.,
terminal software.

Doesn't the BIOS have some character I/O calls for the screen?
I though it did ...  I.e., terminal software could call them.

So long as some terminal software is executing which handles this,
I'd think that the screen and keyboard would work remotely, e.g.,
just like a serial terminal, at least for screen and keyboard,
maybe not the mouse.

> They are only useful to someone who is sitting in front of the machine.

Well, without custom hardware plugging into the AT, PS/2, or USB ports,
or without software such as a terminal emulator running, then true.

> I hadn't thought before how limiting that is if we want to boot an OS  
> but we are not in front of the PC, or the PC does not have a monitor
> attached (as might be true of a headless server).

I was thinking that standard streams could be redirected, e.g., incoming
pipe from network to stdin, etc, if the OS is developed enough.  It's
still a problem with bootloaders, bootsectors, etc.

> Given the above I wonder if it would be a good idea for an OS to include
> an internal model of a console. What I have in mind is basically a small
> text-mode buffer and a means of sending and receiving bytes of text.

How does stdin, stdout, stderr fit?  Same thing?  Different?

> Such a virtual console could be attached to from various places such as:
>
> 1. A serial port. This would allow the kind of interaction that Rod
> alluded to. Someone connecting to that serial port would receive lines
> of text and could issue commands to the OS.
>
> 2. A network port. Once a network driver had been loaded someone could
> connect to the computer console via the network. A simple telnet session
> or an ssh session would do.
>
> 3. Someone sitting at the computer and with a screen and keyboard could
> also be connected to the same type of virtual console. In other words,
> the screen would display the console output in a glass-teletype mode and
> would show the same things that would be sent to someone connected via a
> serial port or over a network. And the virtual console could accept
> commands from the keyboard as it would accept them from a remote
> connection via a serial port.
>
> Option 3 implies that keyboard input would be sent to the virtual
> console, and console updates would be sent to the screen. The only
> downside I can see for using a console approach compared with the
> original situation is that the console would not allow cursor controls.
> To keep the semantics compatible it would also be a line-by-line
> display. But that seems a minor issue and not at all essential.
>

My only real concern is minimizing "cost" by not "reinventing the wheel"
for software, and not developing hardware where a hardware solution exists.
There are a bunch of things present and past which have been or could be
useful: rz/sz, telnet, rtelnet, ssh, ftp, tftp, kermit or CKermit, zmodem,
KVMs, IPKVMs, PXE, BOOTP, BBS menu, etc.

> Does the idea make sense, especially for allowing OS interaction before
> the full OS was up and running?

Being able to emulate the keyboard, mouse, and perhaps text screen would
be useful for virtualization or remote booting, but otherwise, it doesn't
seem to have much value to me.  Obviously, it's needed for what we're
discussing.  I.e., I never understood why Linux is set up with multiple
getty logins on many devices when there is only one user per PC, who uses
a keyboard and mouse, and who only needs to start a shell.  E.g., some of
the logins on this machine were set up to connect to external serial ports
and the internet by default.  Fixing this without permanently locking
yourself out of Linux is a nightmare.  I.e., hacker's wet dream?

> The same console idea could be used to interact with a boot manager or  
> some other program that was not a full OS. That would allow the boot  
> manager to be controlled and a user to select an OS to boot.

So, you're thinking of a miniature terminal application, or a minimal
CLI like an assembly monitor (e.g., DEBUG)? ...

> Once a windowing OS was runing the virtual console could still be there  
> and could be interacted with via a window.

Wouldn't the windowing OS or GUI just take over the functionality?


Rod Pemberton

-- 
Tolerance and socialism attracts intolerance and terrorism.  See:
France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...

Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Use of a virtual console "James Harris" <james.harris.1@gmail.com> - 2015-07-03 10:17 +0100
  Re: Use of a virtual console "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-03 17:47 -0400
    Re: Use of a virtual console "James Harris" <james.harris.1@gmail.com> - 2015-07-03 23:43 +0100

csiph-web