lkml.org 
[lkml]   [2004]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ANNOUNCE: CE Linux Forum - Specification V1.0 draft
Christoph Hellwig wrote:
> CELinux doesn't help either job, it's just listing the implementation details
> of the broken patches of a bunch of companies with vested interest, barely
> mentioning the requirements they try to fullfill.
I disagree. I won't argue that the specifications have their
weaknesses, but the specifications do much more than just
describe implementations. Most of them have normative
sections which describe pretty high-level requirements,
and aren't specific about the possible solutions at all.

Also, I think you've interpreted the linked implementations
incorrectly.

Some of the implementations referenced by the spec are just quick
hacks to demonstrate the problem. The one you pick on below
falls in this category. No one has proposed that this patch
(which obviously is a quick hack, is based on 2.4, and was
never submitted by anyone to LKML) is a solution for the problem.

I think the specification for this particular area is not unclear
at all. The normative section says (in part):
"1. The Linux kernel SHOULD use preemptible waits during IDE driver
initialization, rather than busywaits."

The non-normative section of this spec. explains where this was
a problem in 2.4, and why it is desirable, from the standpoint of
bootup time reduction, to avoid these busywaits.

Further discussion following your post indicates this might not be
a problem in 2.6. This is exactly the type of valuable feedback
CELF appreciates getting from the community, so I fail to see
how the spec., when considered as a communication vehicle, can
be considered "useless".

>
> You'd make our life a lot easier by first writing down the requirement,
> the thinking of soultions instead of taking the one $MEMBERCOMPANY proposed,
> where that thinking shoould involve talking to the mailinglists for that
> area and finally proposing a patch describing _the requirement_, not what
> you've done. CELinux, just like CGL or DCL has very much failed this
> procedure.
Evidence? This is just a rant. It sounds like you don't know
anything about our organization, or what we've done over the
past year. Our requirements working group would be surprised
to find out that CELF didn't methodically gather requirements
from our members. etc. etc.

> So far I can't see CElinux as anything but a useless specication tricking
> PHBs into buying a products of the member companies because they're following
> a specification (of which $PHB of course doesn't know how useless it is)

Christoph,

What on earth are you talking about? CELF includes members who
sell things, but the specification specifically discounts any
claims of conformance. The big members are people like Sony,
Panasonic, Samsung, etc. who are not selling anything to PHBs
(well, except TVs, settops, cellphones, etc, that we hope to
put Linux in. :-)

Our goal is to improve Linux for use in our products.

> If patches aren't even discussed on lkml it means you've done something very
> wrong. I don't really remember any of the patches you submitted on lkml.

We are interested in the Protected RAM File system, which was posted
by MontaVista. We are also interested in high resolution timers,
which was posted by George Anzinger (also, of MontaVista). There
was discussion on both of these, which we noted carefully. We are
currently working on issues that were raised with regard to HRT,
in the hopes of improving its acceptability.

But my main point is that it's incorrect to assume that CELF
is doing nothing, just because things don't come from a CELF e-mail.
(The forum doesn't even provide e-mail accounts.)

> But let's take one of the patches, the first one I looked at on your wiki
> apart:
>...
[bad patch, and rant, removed]

> So if I can give you guys from the various industry consortia some hints:
>
> o think before you code
> o don't drink and code
> o get a clue

As stated above, this patch was not proposed to be a solution for
the problem mentioned in the spec. I agree with you that the code
is quite embarassing. If you see CELF actually submit code like
that to LKML, then please feel free to give us a smackdown. ;-)

In the mean time, your posting of it generated some useful feedback
which is genuinely appreciated.

This last point actually gives me something to think about.
I have resisted sending patches like what you quoted, but
it generated useful comments very quickly. Maybe we should
loosen up and let you see more of our half-baked work?
(But smacking us around doesn't really encourage that...)

Regards,

=============================
Tim Bird
Architecture Group Co-Chair
CE Linux Forum
Senior Staff Engineer
Sony Electronics
E-mail: Tim.Bird@am.sony.com
=============================

-
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/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.094 / U:0.936 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site