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

Groups > alt.os.development > #8288

Re: Use of a virtual console

Show all headers | View raw

"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

Back to alt.os.development | Previous | Next — Previous 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