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 [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]
