LKML Archive on
help / color / mirror / Atom feed
From: Tim Bird <>
To: Christoph Hellwig <>
Cc: Mark Gross <>,
	linux kernel <>
Subject: Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft
Date: Wed, 19 May 2004 12:30:42 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

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)


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...)


Tim Bird
Architecture Group Co-Chair
CE Linux Forum
Senior Staff Engineer
Sony Electronics

  parent reply	other threads:[~2004-05-19 19:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-17 19:05 Tim Bird
2004-05-17 19:19 ` Christoph Hellwig
2004-05-17 19:59   ` Tim Bird
2004-05-17 20:42   ` Mark Gross
2004-05-17 20:48     ` Arjan van de Ven
     [not found]     ` <>
2004-05-18 19:32       ` Mark Gross
2004-05-18 19:56         ` Russell King
2004-05-18 20:45           ` Bartlomiej Zolnierkiewicz
2004-05-18 20:00         ` viro
2004-05-19 19:30       ` Tim Bird [this message]
2004-05-19 21:57         ` Russell King
2004-05-19 22:02           ` Jeff Garzik
2004-05-19 23:46           ` Tim Bird
2004-05-19 22:08         ` Theodore Ts'o
2004-05-19 23:37           ` Tim Bird
2004-05-17 21:22   ` Tim Bird
2004-05-19 15:27     ` Adrian Bunk
2004-05-19 16:59       ` Tim Bird
2004-05-19 20:16         ` Adrian Bunk
2004-05-19 20:38           ` Tim Bird
2004-05-19 20:48             ` Nicolas Pitre
2004-05-19 22:00         ` Russell King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).