[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