Hi Martin, thanks for your input, my comments are below.
On 11/25/2012 09:58 PM, Martin Decky wrote: > 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. There is no conflict here, production builds can have the new functionality disabled too. What I see as another problem of the current kconsole is that some of the applications need to be aware of this purely debugging feature, such as trace, bdsh, console or compositor. While in my branch, only klog is aware of the kconsole. > 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. Well, my change removes some of the debugging strength, but on the other hand, I would not go as far as saying that it is not powerful enough. It's just less powerful. Definitely much more powerful than without any kconsole support. Whether it is not powerful enough needs to be established. Some features are removed, yes, but it also makes it possible for the uspace drivers to evolve (see Jano's response to the original mail) and still have a way of communicating with kconsole. >> - 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. Yes, USB is a nice example I did not originally think about. >> - 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. Do we know under what circumstances can klog loose output? Is it likely to happen? As of now, I seem to be having the opposite problem, i.e. redundant output. >> - 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. Unfortunately yes. How often did we make use of this possibility? I remember I used this a couple of times myself, but could probably do without it. This capability can be partially substituted by the debugging facilities of the simulators we use. On the bright side of things, we will be able to get rid of some or even all kernel driver code, which is only for debugging purposes, is suboptimal and incomplete but still needs to be maintained. > 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. I also thought about a similar possibility, but the kconsole is actually useful as an interpreter. It allows you to directly execute kernel functions in a context of a kernel thread, have them run on other processors, read/write PIO registers and do other stuff for which it would not be practical or wise to have a debugging syscall or write a specialized user program. >> - 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). Well, this is the optional part of my plan. > 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. I have always thought about the kconsole step as a precondition for removing all or most of the kernel drivers (timers, interrupt controllers etc.) in favour of purely uspace ones. I would actually try to go even a little farther than that. For example, I don't like the fact that the kernel starts the other CPUs and deals with stuff such as the ACPI tables. I would therefore make it possible for the uspace drivers to detect the additional CPUs and activate them so that the kernel does not have to care about it. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
