On 10/6/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote: > On Sat, 6 Oct 2007 01:01:10 +0200 > "Miguel Ojeda" <[EMAIL PROTECTED]> wrote: > > > On 10/5/07, Rob Landley <[EMAIL PROTECTED]> wrote: > > > On Friday 05 October 2007 2:01:08 am Miguel Ojeda wrote: > > > > > > > > I think we all are trying to give ideas to improve the current logging > > > > API. > > > > > > > > If something works, it's great; but it doesn't mean that it can't be > > > > improved, right? > > > > > > I'm all for improving the kernel, but my definition of "improved" does not > > > include every possible change. I balance "smaller and simpler" with "more > > > features". Complexity is a cost, we should get something in return. > > > > > > Making the same functionality simpler makes it "cheaper" from a > > > development > > > standpoint. Smaller and simpler means less overhead, less to understand, > > > less to go wrong. It's also attractive to me personally, because I am a > > > Bear > > > of Very Little Brain and between the dozen or so projects I try to > > > follow, I > > > have trouble fitting all the details in my head when they're tricky or > > > they > > > change ever time I look at them. (Especially when I get distracted from > > > one > > > of those projects for 3-6 months and come back to find it changed.) > > > > I fully agree. However, I just gave away some ideas that I believe > > they can make printk() easier and more understandable than it is right > > now (for example, standardizing kprint_[registered,detected,...] > > messages is something that I think it can simplify everyday use of > > messages, both to people who has to code it, review/search the code > > and people that reads the kernel output). > > > > > > > > I recognize constantly having to learn new things as part of the cost of > > > living, and making things more complicated happens as you add features. > > > But > > > when somebody reinvents the wheel it's really nice to have clearly spelled > > > out the advantages of the new wheel vs the old one. It's nice for there > > > to > > > _be_ clear advantages, offsetting the increased complexity cost. > > > > I got your point, and I agree. However, I also see the possibilities > > that a change of the logging API can bring: If someday it gets > > improved, maybe such day should be improved as far as possible. This > > kind of stuff that affect so many things are not going to change for > > long periods of time, as you said. > > > > Still, I know some kind of changes can be really complex and maybe are > > unproductive. I think the point is to get a middle point between new > > complexity vs. new features. > > > The beauty of printk is it's current simplicity. And even with that > developers > get it wrong. The changes seem like added complexity with little real gain. > > Plus none of the changes address the issue of getting better information. > The kernel is already so noisy that most distributions boot with the quiet > flag to shut it up. So less messages is probably better! >
I agree. On the one hand, some changes are complex (like "blocks" implementation) and maybe they will not help at all. I'm not agreeing with every change :) On the other hand, the new tags (more standarized messages and simplified code) and all the information given by the new syslog retrieved from userspace (formatted messages => better information possibly) can do a lot of good (and maybe even more in the future, with a lot more stuff inside the kernel), without creating noise at boot at all. That kind of changes I think they would do more good than bad. -- Miguel Ojeda http://maxextreme.googlepages.com/index.htm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/