Messages in this thread |  | | From | Rob Landley <> | Subject | Re: [RFC] New kernel-message logging API | Date | Sun, 23 Sep 2007 15:05:37 -0500 |
| |
On Saturday 22 September 2007 2:27:29 pm Vegard Nossum wrote: > After recent discussions on LKML and a general dissatisfaction at the > current printk() kernel-message logging interface, I've decided to > write down some of the ideas for a better system. > > > Requirements > ============ > > * Backwards compatibility with printk(), syslog(), etc.
I.E. what we have now works just fine for what it does.
> * Extensibility. Features like timestamping or file/line recording > [1] should be both selectable at compile-time and (if compiled in) at > run-time.
That doesn't require changing the API. Allowing the compiler to eliminate messages below a threshold requires changing the API.
> > API > === > > #define kprint(fmt, ...) > > The main part of the kprint interface should be the kprint() function.
And then you propose not having a single kprint() function...
> To support the different log-levels, there exists one kprint_*() > function for each log-level, for example kprint_info().
Why is this better than feeding the level in as an argument to the macro?
> In order to print several related lines as one chunk, the emitter > should first allocate an object of the type struct kprint_buffer.
You know, I'm pretty happy with a first pass that doesn't address this issue at all. Why bundle three unrelated problems into a single all-or-nothing pass?
Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |