Re: [RFC][PATCH] New message-logging API (kprint)

[Rob Landley]

On Friday 05 October 2007 2:01:08 am Miguel Ojeda wrote:
> > Last I checked, the current prink() worked just fine.  Why is this _not_
> > the dreaded "infrastructure in search of a use"?  What exactly can we
> > _not_ do with the current code?  What does this allow us to remove and
> > simplify?
> >
> > I'm confused about what people are trying to accomplish here...
>
> 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 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.

In this case, upon asking, the only potential advantage here seems to be "now 
we can translate dmesg output into Chinese more easily", which is something 
you could already do in userspace already via regular expressions in a 
translating dmesg, and which has the primary effect of making the resulting 
dmesg useless to report to lkml without really improving the amount of sense 
it makes to nontechnical end users (who really aren't the target of the 
english dmesg output, either).  The "linux developer who can't read english" 
niche is inherently somewhat problematic, as has been discussed here before.

The cost of this patch is making the kernel bigger, the in-kernel printk api 
more complicated, and the userspace dmesg noticeably more complex just to 
implement the same functionality against the new API.  Documenting the 
changes is nice, but doesn't reduce this increase in complexity.

The original idea (selectively compile out printk() instances based on log 
level to conserve space) is explicitly not addressed by this patch, and in 
fact this patch might actually make it harder to implement (by complicating 
the code).

*shrug*  That doesn't mean my objections are important to anyone else, just 
that I don't personally see any reason to be enthusiastic about this patch.

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/