Hi Jakub,
it is definitively an interesting way to go, but perhaps we should not
go too far with this. Or, alternatively, we should go as far as possible
(explained below).
I still consider the kernel console as a debugging tool which should be
completely absent from any "production" build (once we do production
builds, that is :)) and no user space functionality should depend on it.
But this also means that severely limiting the features of the kernel
console does not make much sense -- you don't want or need a debugging
tool that is not powerful enough, that is not available or useful when
you need it to debug something, etc.
- the sys_klog() syscall is used to feed kconsole commands directly to
kernel stdin
This is a part I certainly won't object to. It should allow to use the
kconsole with USB input devices, over the network, etc.
- it is no longer possible to switch to kconsole (Alt+M, F12, kcon)
- the only two occasions when the kernel prints directly to the stdout
is before the uspace takes the console over and when the system panics;
other than that, all communication with kconsole is done using klog and
the kernel does not touch the devices
Well, I don't know here. The klog communication with the kernel is
best-effort by design (there is deliberately no synchronization and
blocking), thus you can loose output in certain cases. But sometimes you
want a guaranteed output which only a synchronous output driver in the
kernel can provide.
Alternatively, we can have an alternative synchronous way of
transferring the klog output to user space which will be used in special
cases.
- remove all kernel input drivers (which was one of the biggest
motivations for this change)
But in that case you loose the early boot debugging possibility.
If you really go that way, you can probably remove the kconsole
subsystem completely (keeping just the kernel output). You can have a
special debugging syscall for running the kernel tests and you can
access all the data provided by the other kconsole commands via dynamic
sysinfo subtrees, thus removing the other interactive kconsole commands
completely.
- optionally remove most of the kernel output drivers and keep e.g. only
serial ones
But if you remove e.g. the framebuffer driver, you loose the boot
diagnostics on platforms which don't have any kernel serial driver (e.g.
ppc32).
And again, if you really go that way, why keeping any connection between
the kernel log and the user space log? Both can be completely isolated.
I mean, OK, let's rethink the kconsole subsystem. But we should either
keep it mostly intact with only minor modifications (if we like the
debugging possibilities) or rip it away completely (if we like a clean
design). Keeping it crippled with combined drawbacks of both solutions
is not very beneficial.
M.D.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
