[ros-kernel] /CONSOLE switch

Aliberti Emanuele ea at iol.it
Wed Sep 1 23:48:57 CEST 2004


Hi Gé,

I am sorry for the late reply. I posted a message yesterday, but I used 
an address that can not post.

>> <>My plan was to have ntoskrnl set a registry value based on the presence
>> or absence of /CONSOLE. That would be the end of the involvement of the
>> kernel. The winlogon behaviour described above would then be keyed on
>> that registry value. I'm not sure if I understand you correctly, but are
>> you saying that I should scrap the ntoskrl part but the winlogon part is
>> ok (just need another method to set the registry key)? That would kill
>> one of the nice features: being able to boot into console mode on a
>> system which normally runs in graphics mode, for the purpose of making
>> repairs. Also note that there is some "prior art" wrt. boot options and
>> registry values: this is exactly what the NT4 /BASEVIDEO switch does.
>>
I am sorry for my bad English: this adds noise to what I write.

I support booting in text mode since the beginning and voted against 
dropping it when the GUI was to take off.

That said, making the winlogon perform its i/o in graphic mode or in 
text mode, IMHO, should not depend on a bare value stored in the 
registry by the kernel. Instead each system component should be prepared 
to run in both modes (or, if not possible at all, to die), depending on 
the value returned by a specific API available in the SM - say the 
server registered at slot # 1 in the SM (slot # 0 is for the SM itself). 
This does not mean every process should query the SM, but that it exists 
a way to broadcast a global mode switching to every subsystem. In fact 
it is the SM that loads win32k.sys (in the real NT, is that event an on 
demand event [CSRS rings the SM: "Hi boss, please load a piece of mine 
in the kernel!"], or a predefined event?).

That behaviour - properly switching from GUI to text mode and back, 
keeping the full context, whenever possible - should be a real 
innovation compared to NT. NT had text mode at the beginning, when the 
dominant subsystem was OS/2. If you look at the OS/2 subsystem 
components in NT, you see that they are similar to the CSRSS plus the 
W32 plug-ins. OS/2 is text mode only, unless you buy the PM for NT (it 
used to be available ages ago from MS). Unices and Linux have both text 
and graphic mode (various flavours), and you can switch between.

Booting in text mode is not only nice when you need to do repairs. It'd 
be also very useful in a system that runs *normally* in text mode, that 
can be switched in GUI mode for maintenance, and then downgraded to text 
mode again for its normal running. Does it look like typing startx and 
pressing return? Not exactly. If I am in a vim session and shell out to 
run startx, what I get is not a gvim blocked waiting for me to type exit 
in a xterm. Ros would impress users if, started in text mode, after 
running three of four cmds, switching on the GUI would show three or 
four windows with a cmd each inside.

For compatibility, /BASEVIDEO should make the system behave like in NT 
5.x (using the VGA video mode).

/CONSOLE recalls the "console" concept, which is the default I/O 
character device the operator can choose at the beginning of the 
boostrap process (AIX prints something like "press 1 here to make this 
terminal the system console", on every terminal physically attached to 
the planar). If we want to add such an option, it souldn't be boolean; 
it should at least be possible to force the kernel to use a specified 
device as the default console. For instance

/CONSOLE=COM1
/CONSOLE=VIDEO0
/CONSOLE=UDP*IP*192.168.1.42
/CONSOLE=IRDA0
...

(well it looks like /DEBUGPORT=, perhaps because the debug port is a 
terminal)

What I am actually again is mixing up a legacy consoles and W32 
consoles. For W32 consoles as the sole output device of the system, I 
suggest a switch like /CUIBOOT (implies W32).

Emanuele Aliberti


More information about the Ros-kernel mailing list