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

Groups > alt.os.development > #8276 > unrolled thread

Use of a virtual console

Back to article view | Back to alt.os.development

Contents

  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

#8276 — Use of a virtual console

Something Rod said 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.

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.

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. They are only 
useful to someone who is sitting in front of the machine. 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).

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. 
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.

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

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.

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

Comments? Thoughts?

James

[toc] | [next] | [standalone]

#8285

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, ...

[toc] | [prev] | [next] | [standalone]

#8288

"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
news:op.x07v5hdbyfako5@localhost...
> 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.

Similarly, I love the simple old teletype model of commands and 
responses. It seems a straightforward and sensible way to interact with 
an OS (for control purposes, not GUI stuff) and you could always look 
back and see exactly what was typed and what responses you got.

> 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? ...

As you seem to suggest, the old console model is still alive and well, 
and for very good reasons.

>> 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.

I don't know how they are to be distinguished either. I *often* find 
Linux componentisation confusing.

>> 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?

That wouldn't work once in protected mode with a direct KBC driver 
running.

> 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?

Yes. But it also has things like a write-char-at option which would not 
work over a line-by-line interface.

> 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 suppose I am thinking that someone should be able to use a serial port 
or a network connection or any other suitable connection and get 
bidirectional ASCII communication with the OS. The 'person' at the end 
of the line doesn't even need to be a human. A program could interact 
with the OS just as easily.

>> 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.

You might be right. I hadn't thought about using stdin/out/err. I 
suppose the main difference between a shell idea and the idea of a 
console is that I think the OS could emit a line of informational text 
unsolicited to the console at any time ... maybe.

>> 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?

I don't know. If line-by-line (what I think is called cooked mode rather 
than raw) perhaps they would be the same thing.

At the end of the day this is just an outline of an idea. If someone 
implemented something like it then the choices he made might vary from 
those someone else made.

...

> My only real concern is minimizing "cost" by not "reinventing the 
> wheel"
> for software, and not developing hardware where a hardware solution 
> exists.

You know, the idea of a console into an OS is maybe a wheel that does 
not need to be reinvented because it is a classic concept that needs no 
update.

> 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.

Of those would an IPKVM idea fit most closely with what you wanted, i.e. 
a hypervisor which could be accessed remotely and on which you could run 
OS images?

>> 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.

OK.

...

>> 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)? ...

Yes, sort of. In summary:
* Line-by-line input and output.
* The OS would send selected lines for info and responses to commands.
* A command would be typed at the bottom of the screen and echoed in the 
main part of the screen when complete, followed by the response.
* The same console would be accessible via serial line and network, and 
by any other suitable port type, and via the directly-attached keyboard 
and monitor, so it would look the same regardless of how a person 
accessed it.
* The same console would continue to be accessible in a terminal window 
once the windowing environment was singing and dancing.
* The interface to the console would always be of the simple 
glass-teletype kind with no graphics and no updates anywhere except at 
the bottom.

>> 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?

I was thinking that even with a GUI running the OS console would 
continue to run in the background and that it could be connected-to by 
various means, security permitting.

James

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.development

csiph-web