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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
