Date: Wed, 19 Sep 2007 12:31:50 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Marcel Moolenaar <xcllnt@mac.com> Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() Message-ID: <20070919193150.GM79417@elvis.mu.org> In-Reply-To: <96A863DB-3C0B-4AD0-B0A1-3C0A89B42C75@mac.com> References: <96A863DB-3C0B-4AD0-B0A1-3C0A89B42C75@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Marcel Moolenaar <xcllnt@mac.com> [070919 12:16] wrote: > All, > > With FreeBSD being used in various situations, including the embedded > space, there seems to be an increasing need to have fine-grained > control over what the kernel prints to the console during boot as well > as during normal operation. It is my believe at least that the all or > nothing approach that we have now is inadequate. > > With this email I'd like to start a discussion in an attempt to get > some feel for what is possible and/or acceptable as well as get more > information about the situations where the current behaviour of > FreeBSD had to be changed (or people wished it would change). > > We currently have standard, verbose and mute. Standard is really > already too verbose from a regular user (i.e. non-developer) > point of view. Mute is really not adequate, because you may want > to print at least the copyright notice or provide a couple of > lines of critical information even when you don't wont to see > anything else. > > On top of that, if we shift our thinking towards the theoretical, > futuristical and/or luxurious then we may be faced with multiple > output devices, such as a small LCD, onto which we want to print > some status information. With multiple output devices we may want > to channel different kinds of messages to different devices. > > As a first stab, I'm thinking that if we amend the printf()s with > a syslog-type facility and/or level, we may achieve just that. > Replacing printf with klog() and change the printf implementation > to be in terms of a klog call with an as of yet unspecified level > and/or facility would help migrate from one system to another. > > What do people think of such an ability? > > Have people implemented something similar as part of their own > FreeBSD-based solutions? > > If we have the ability to suppress certain kinds of output, > do we still want save the supressed output somewhere and do > we want to be able to have fine-grained control over that too? Marcel, A while ago I was faced with a similar issue, mostly dealing with debug levels. What I came up with was an IDL for defining debug levels and an API for accessing them via string lookup. In effect one could define a tree, akin to sysctl that provided all these layers. Additionally the API allowed for recursive incrementing and decrementing the nodes in the tree. Effectively a description file like this: all all.kern all.kern.dev all.kern.dev.fxp all.kern.dev.fxp.rx all.kern.dev.fxp.tx all.kern.nfs all.kern.nfs.client all.kern.nfs.client.nfsiod all.kern.nfs.server .. Then inside the program one would simply write: alfred_printf(all_kern_dev_fxp, 1, "Fxp initialized"); then maybe in the rx routine: alfred_printf(all_kern_dev_fxp_rx, 2, "Fxp got packet"); the IDL "compiler" would emit a header with extern declarations for all of these integers and a C file with then instantiated along with a lookup table to map strings to these integers. A small library would then allow for the operations to either increase or decrease a particular debug integer or recursively operate on a subtree. This allowed one to for instance make fxp _very_ verbose for a short time. Since the alfred_printf directly pointed at the integer in question the overhead of not printing was simply a branch. For extremely hot spots I would conditionally compile in the code for logging, but in practice this was hardly needed. You could see this being a system where all.kern.log is set to 1 by default, with everything off, an api for setting log variables via the loader (tunables) would provide for adequate means of setting the debug knobs early on. One last facility that I have implemented, but not within the same system is a count-down for how many log records to emit. for instance, I may want to sample about 1000 records from fxp, therefore I would provide a count down integer for the driver itself that would be set to 1000 and if both the log level is set, AND the integer is greater than zero, then the log message would be emitted as well as the integer decremented. -- - Alfred Perlstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070919193150.GM79417>