ANNOUNCE: CE Linux Forum - Specification V1.0 draft

ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Tim Bird]

I am writing to announce the availability of the first draft of
the CE Linux Forum's first specification.  This specification
represents the efforts of six different technical working groups
over about the last 9 months.

The specification is available at:
http://tree.celinuxforum.org/docs/CELF_Specification_V_1_0_R1-1.pdf

The specification is also available online, and individual pages
may be viewed on the forum wiki, at:
http://tree.celinuxforum.org/pubwiki/moin.cgi/FrontPage

Included in the document are specifications or notes on technologies
in the areas of:
  - Bootup time reduction
  - Power management
  - Audio/Video/Graphics
  - Realtime features
  - System size reduction
  - Security

Please see the introduction of the document for more details on the
scope and purpose of the document.  Some of the technologies mentioned
in the document are already integrated into 2.6.  You should start
to see others submitted here individually for your consideration
in the near future.

Please note that this draft has not yet been approved or ratified
by the forum at this time.

Any and all feedback is welcome, via either the forum's public
mailing list at celinux-dev@tree.celinuxforum.org, or on this list.

Thanks,

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

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Christoph Hellwig]

On Mon, May 17, 2004 at 12:05:36PM -0700, Tim Bird wrote:
> I am writing to announce the availability of the first draft of
> the CE Linux Forum's first specification.  This specification
> represents the efforts of six different technical working groups
> over about the last 9 months.

If you want my 2Cent:

 - stop these rather useless specifications and provide patchkits instead
 - try to actually submit the patches upstream to get a feeling which
   of your 'features' are compltely hopeless, which are okay and which
   can better be solved in different ways.

(same applies to CGL/DCL/$INDUSTRYCONSORTIUM)

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Tim Bird]

Christoph Hellwig wrote:

> On Mon, May 17, 2004 at 12:05:36PM -0700, Tim Bird wrote:
> 
>>I am writing to announce the availability of the first draft of
>>the CE Linux Forum's first specification.  This specification
>>represents the efforts of six different technical working groups
>>over about the last 9 months.
> 
> 
> If you want my 2Cent:
> 
>  - stop these rather useless specifications and provide patchkits instead
>  - try to actually submit the patches upstream to get a feeling which
>    of your 'features' are compltely hopeless, which are okay and which
>    can better be solved in different ways.

Thanks.

I strongly agree with you.  I hope that the specifications are not
completely useless.  Hopefully they are good to provide context,
rationale, etc.  However, sending patches upstream is far superior,
and I hope to be able to start sending a stream of them, based
on this work, very soon.

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

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Mark Gross]

On Monday 17 May 2004 12:19, Christoph Hellwig wrote:
> On Mon, May 17, 2004 at 12:05:36PM -0700, Tim Bird wrote:
> > I am writing to announce the availability of the first draft of
> > the CE Linux Forum's first specification.  This specification
> > represents the efforts of six different technical working groups
> > over about the last 9 months.
>
> If you want my 2Cent:
>
>  - stop these rather useless specifications and provide patchkits instead
>  - try to actually submit the patches upstream to get a feeling which
>    of your 'features' are compltely hopeless, which are okay and which
>    can better be solved in different ways.

All that these "organizations" are doing is collecting REAL requirements for 
features that REAL application developers need.  As well as putting up 
resources to enable the features.

These features represent input from real application developers and system 
integrators on requirements that would be cool for their applications if 
Linux supported them.  Why not look at them from the "what features are 
missing from Linux today and by whom" point of view?

It is also true that most of the requirements exist only if there is some type 
of implementation available.  As such patches for many of the components of 
such specifications are by definition already available at the time of the 
announcement.  (most may need significant work to bring up to date with the 
current kenrel tree, but they do exist)  

The patches do get submitted on a regular basis to the LKML.  Many seem to get 
ignored.  Some of them should, but it seems to me that if features keep 
coming up as requirements in such "specifications" and resources continue to 
work on the feature, then there must be some real need for it.  

BTW, Has anyone actually looked at the latest high res timer patch for 2.6.5?  
I has a new design for the sub-jiffies timer interrupt source.  

It provides an implementation of a the missing feature of low jitter (< 1ms), 
system wide time base via a standard API. ( POSIX would be nice)  

--mgross
My opinions are my own and not that of my employer, duh.

>
> (same applies to CGL/DCL/$INDUSTRYCONSORTIUM)

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Arjan van de Ven]

> ations" are doing is collecting REAL requirements for 
> features that REAL application developers need.  As well as putting up 
> resources to enable the features.


it really looks more that all of the ones Christoph mentioned are about
merging the list of patchkits from the vendors involved than about real
requirements.

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Mark Gross]

On Monday 17 May 2004 23:48, Christoph Hellwig wrote:
> On Mon, May 17, 2004 at 01:42:49PM -0700, Mark Gross wrote:
> > All that these "organizations" are doing is collecting REAL requirements
> > for features that REAL application developers need.  As well as putting
> > up resources to enable the features.
> >
> > These features represent input from real application developers and
> > system integrators on requirements that would be cool for their
> > applications if Linux supported them.  Why not look at them from the
> > "what features are missing from Linux today and by whom" point of view?
>
> Have you ever worked ina real life software shop?  For every given feature
> X you can find N customers X1...XN that will declare they want this
> feature. Even more for every given customer Y you'll always find M feature
> he'll absolutely want.  Until you tell him it's not in the next version
> unless he provides founding where the feature set usually gets shrunk down
> a lot.
>

I have worked in a number of real life software shops.  The more effective 
shops I've worked in have been those where the developers where open minded 
enough to read the "requirements" to extract the true needs.  

I'm sensing you are not so open minded about recognizing requirements and 
needs.

> Even the most clueless project manager gets this, and the engineering
> response cuts down this list a lot.
>

so.

> With many of the large opensource projects this traditional scheme pretty
> much falls flat because for every given feature F there's always N broken
> implementations and the 'project managers' solution is rather to filter
> what features are usefull enough and what implementation is good enough.
>

It seems to me that these organization are doing just this.  Those features or 
requirements that stick across major revisions of such specifications and 
become more stable are likely the usefull enough features with good enough 
implantation's, that are worth looking at.

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

Yeah, the decomposition of the features/implementations to requirements does 
need work in these things.  CELF is a new group.  However; I think CGL isn't 
so bad at this.

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

I agree that patches should get posted with requirement and implementation 
detail in addition to the patch itself.  However; I see a lot of patches that 
provide neither posted by every one.

> 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)
>
> > The patches do get submitted on a regular basis to the LKML.  Many seem
> > to get ignored.
>
> 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.

I didn't post it.

>
> But let's take one of the patches, the first one I looked at on your wiki
> apart:

Lets not.  

This about requirements, missing features and needs aplication developers 
have.  The example below is simply one patch to enhance the kenrel latency 
for applications using IDE drives.  Its also an old patch for an older 
kenrel.

This topic is not about implementation pulled out of some embedded linux 
kernel hack implemented by some CE company in the past to work around latency 
issues with a base kernel that didn't have good kernel preemption behavior.  

This topic is about features that are worth considering and enhancements 
needed by your users.

The follow snippet is clearly an implementation attempting to fullfill some 
type of latency requierement that the IDE implementation was blocking.

Actualy I think this code may be related to boot time reduction.  It may be 
worth looking at the CELF specification to see if there is a boot time 
reduction section.

>
> --- linux-2.4.20.orig/drivers/ide/ide.c	Thu Nov 28 23:53:13 2002
> +++ celinux-040213/drivers/ide/ide.c	Thu Feb 12 10:25:12 2004
> @@ -2739,12 +2776,17 @@
>   */
>  void ide_delay_50ms (void)
>  {
> +#ifdef CONFIG_IDE_PREEMPT
> +	__set_current_state(TASK_UNINTERRUPTIBLE);
> +	schedule_timeout(1+HZ/20); /* from 2.5 */
> +#else /* CONFIG_IDE_PREEMPT */
>  #ifndef CONFIG_BLK_DEV_IDECS
>  	mdelay(50);
>  #else
>  	__set_current_state(TASK_UNINTERRUPTIBLE);
>  	schedule_timeout(HZ/20);
>  #endif /* CONFIG_BLK_DEV_IDECS */
> +#endif /* CONFIG_IDE_PREEMPT */
>  }
>
> This great piece 'called IDE-preempt' to be buzzword-compliant is (and
> that's noticeable just from looking at the diff!) so braindead that it's
> not explainable by incompetence alone.  You'd get your same result by just
> _disabling_ CONFIG_BLK_DEV_IDECS instead of adding another broken config
> option (modulo 2.6 adjustments to the sleep time).
>
> Every engineer with the slightest clue would first disable that option, or
> if ide-cs support is actually needed think _why_ it's different instead of
> just adding a config option to disable it.  Either it's safe to always use
> the sleeping variant in which case the original ifdef should go away, or
> it's not in which case your patch is completely broken.
>

OK I'll bite, but just because in your blind hostility and haste you've made a 
mistake ;)

Just taking this code out of context (typically a bad thing to do) I would say 
you would like to have CONFIG_BLK_DEV_IDECS enabled.  Note the "#ifndef" to 
avoid the mdelay call.  However; this wont help much if you don't have your 
IDE drive connected to a PCMCIA adapter and you are using the card services 
driver.

Most REAL software shops that ship product end up having to make such hacks to 
enable critical paths for applications and avoid the implementation of more 
general solutions based on engineering costs.  This patch is clearly a hack 
to enable partial or enhance kernel preemption on the ide path. 

These are some of the types of problems engineers at REAL software shops have 
to solve to be able to ship REAL product for REAL money.  If you haven't HAD 
to produce code like this yourself at some point in your carrier then you've 
lived a sheltered life.

Its disingenuous for you to get on your ivory tower to point and laugh.

> 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

It would be cool if you could be a bit more open minded about what these 
organizations are doing and consider the requirements and the needs they are 
trying to address.

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Russell King]

On Tue, May 18, 2004 at 12:32:48PM -0700, Mark Gross wrote:
> > --- linux-2.4.20.orig/drivers/ide/ide.c	Thu Nov 28 23:53:13 2002
> > +++ celinux-040213/drivers/ide/ide.c	Thu Feb 12 10:25:12 2004
> > @@ -2739,12 +2776,17 @@
> >   */
> >  void ide_delay_50ms (void)
> >  {
> > +#ifdef CONFIG_IDE_PREEMPT
> > +	__set_current_state(TASK_UNINTERRUPTIBLE);
> > +	schedule_timeout(1+HZ/20); /* from 2.5 */
> > +#else /* CONFIG_IDE_PREEMPT */
> >  #ifndef CONFIG_BLK_DEV_IDECS
> >  	mdelay(50);
> >  #else
> >  	__set_current_state(TASK_UNINTERRUPTIBLE);
> >  	schedule_timeout(HZ/20);
> >  #endif /* CONFIG_BLK_DEV_IDECS */
> > +#endif /* CONFIG_IDE_PREEMPT */
> >  }
> >
> > This great piece 'called IDE-preempt' to be buzzword-compliant is (and
> > that's noticeable just from looking at the diff!) so braindead that it's
> > not explainable by incompetence alone.  You'd get your same result by just
> > _disabling_ CONFIG_BLK_DEV_IDECS instead of adding another broken config
> > option (modulo 2.6 adjustments to the sleep time).
> >
> > Every engineer with the slightest clue would first disable that option, or
> > if ide-cs support is actually needed think _why_ it's different instead of
> > just adding a config option to disable it.  Either it's safe to always use
> > the sleeping variant in which case the original ifdef should go away, or
> > it's not in which case your patch is completely broken.
> >
> 
> OK I'll bite, but just because in your blind hostility and haste you've made a 
> mistake ;)

Christoph is actually making a valid point here and I suspect is trying
to point out the lack of thought put into this change.  The things that
_should_ have been considered before making the change are:

1. Why do we use mdelay() here if CONFIG_BLK_DEV_IDECS is defined?

2. Is the reason for this still valid?

3. If it is safe to sleep here even if CONFIG_CLK_DEV_IDECS is set,
   why bother with mdelay() in the first place?

The _correct_ patch is actually:

 void ide_delay_50ms (void)
 {
-#ifndef CONFIG_BLK_DEV_IDECS
-	mdelay(50);
-#else
 	__set_current_state(TASK_UNINTERRUPTIBLE);
 	schedule_timeout(HZ/20);
-#endif /* CONFIG_BLK_DEV_IDECS */
 }

since PCMCIA always calls drivers from process context now.




(Unfortunately I can't write upside down, but I'll give the answers to
those three items above.  Look away now if you don't want to read the
answers! 8) )


1. PCMCIA used to call drivers in IRQ context, which made it impossible
   to sleep.

2. No, because PCMCIA always calls drivers in process context now, so
   sleeping is possible.

3. Left as an exercise to the reader. 8)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Bartlomiej Zolnierkiewicz]

On Tuesday 18 of May 2004 21:56, Russell King wrote:
> On Tue, May 18, 2004 at 12:32:48PM -0700, Mark Gross wrote:
> > > --- linux-2.4.20.orig/drivers/ide/ide.c	Thu Nov 28 23:53:13 2002
> > > +++ celinux-040213/drivers/ide/ide.c	Thu Feb 12 10:25:12 2004
> > > @@ -2739,12 +2776,17 @@
> > >   */
> > >  void ide_delay_50ms (void)
> > >  {
> > > +#ifdef CONFIG_IDE_PREEMPT
> > > +	__set_current_state(TASK_UNINTERRUPTIBLE);
> > > +	schedule_timeout(1+HZ/20); /* from 2.5 */
> > > +#else /* CONFIG_IDE_PREEMPT */
> > >  #ifndef CONFIG_BLK_DEV_IDECS
> > >  	mdelay(50);
> > >  #else
> > >  	__set_current_state(TASK_UNINTERRUPTIBLE);
> > >  	schedule_timeout(HZ/20);
> > >  #endif /* CONFIG_BLK_DEV_IDECS */
> > > +#endif /* CONFIG_IDE_PREEMPT */
> > >  }
> > >
> > > This great piece 'called IDE-preempt' to be buzzword-compliant is (and
> > > that's noticeable just from looking at the diff!) so braindead that
> > > it's not explainable by incompetence alone.  You'd get your same result
> > > by just _disabling_ CONFIG_BLK_DEV_IDECS instead of adding another
> > > broken config option (modulo 2.6 adjustments to the sleep time).
> > >
> > > Every engineer with the slightest clue would first disable that option,
> > > or if ide-cs support is actually needed think _why_ it's different
> > > instead of just adding a config option to disable it.  Either it's safe
> > > to always use the sleeping variant in which case the original ifdef
> > > should go away, or it's not in which case your patch is completely
> > > broken.
> >
> > OK I'll bite, but just because in your blind hostility and haste you've
> > made a mistake ;)
>
> Christoph is actually making a valid point here and I suspect is trying
> to point out the lack of thought put into this change.  The things that
> _should_ have been considered before making the change are:
>
> 1. Why do we use mdelay() here if CONFIG_BLK_DEV_IDECS is defined?

why we don't, it is ifndef not ifdef

> 2. Is the reason for this still valid?
>
> 3. If it is safe to sleep here even if CONFIG_CLK_DEV_IDECS is set,
>    why bother with mdelay() in the first place?

even ifndef

> The _correct_ patch is actually:
>
>  void ide_delay_50ms (void)
>  {
> -#ifndef CONFIG_BLK_DEV_IDECS
> -	mdelay(50);
> -#else
>  	__set_current_state(TASK_UNINTERRUPTIBLE);
>  	schedule_timeout(HZ/20);
> -#endif /* CONFIG_BLK_DEV_IDECS */
>  }
>
> since PCMCIA always calls drivers from process context now.

Probably somebody got the logic wrong while adding this ifndef.

I've checked (quickly) all users of ide_delay_50ms() + their callers
and it seems that this change is safe.

Cheers.

>
> (Unfortunately I can't write upside down, but I'll give the answers to
> those three items above.  Look away now if you don't want to read the
> answers! 8) )
>
>
> 1. PCMCIA used to call drivers in IRQ context, which made it impossible
>    to sleep.
>
> 2. No, because PCMCIA always calls drivers in process context now, so
>    sleeping is possible.
>
> 3. Left as an exercise to the reader. 8)

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[viro]

On Tue, May 18, 2004 at 12:32:48PM -0700, Mark Gross wrote:
> These are some of the types of problems engineers at REAL software shops have 
> to solve to be able to ship REAL product for REAL money.  If you haven't HAD 
> to produce code like this yourself at some point in your carrier then you've 
> lived a sheltered life.
>
> Its disingenuous for you to get on your ivory tower to point and laugh.

	Well, you see, after spending years cleaning up the excrements
of self-styled "REAL engineers" it's either get on the tower to point and
laugh or get on the tower to point and shoot.

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Tim Bird]

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

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Russell King]

On Wed, May 19, 2004 at 12:30:42PM -0700, Tim Bird wrote:
> 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.

In this case, it's really a bug that IDE is using a busy wait where it
should be using a sleeping wait.  It's a bug, plain and simple.  To
wrap the bug into "a spec" somehow seems wrong to me, especially when
it would be far better to report the problem as a bug.

Sure, specs make suit-wearing people happy, but that doesn't mean that
they're appropriate as a bug reporting method. 8)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Jeff Garzik]

Russell King wrote:
> On Wed, May 19, 2004 at 12:30:42PM -0700, Tim Bird wrote:
> 
>>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.
> 
> 
> In this case, it's really a bug that IDE is using a busy wait where it
> should be using a sleeping wait.  It's a bug, plain and simple.  To
> wrap the bug into "a spec" somehow seems wrong to me, especially when
> it would be far better to report the problem as a bug.
> 
> Sure, specs make suit-wearing people happy, but that doesn't mean that
> they're appropriate as a bug reporting method. 8)

Use libata, which does polling and sleeping ;-)

	Jeff

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Tim Bird]

Russell King wrote:
> On Wed, May 19, 2004 at 12:30:42PM -0700, Tim Bird wrote:
> 
>>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.
> 
> In this case, it's really a bug that IDE is using a busy wait where it
> should be using a sleeping wait.  It's a bug, plain and simple.  To
> wrap the bug into "a spec" somehow seems wrong to me, especially when
> it would be far better to report the problem as a bug.

Sometimes it's difficult to discern what the intention or correctness
of a piece of code is, when you have limited experience with the code.
I know, we could have just asked...

> 
> Sure, specs make suit-wearing people happy, but that doesn't mean that
> they're appropriate as a bug reporting method. 8)

Agreed.  :-)  We should probably mutate this into a more general
statement that says "busywaits are not appreciated as a delay mechanism
by drivers on bootup."

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

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Theodore Ts'o]

On Wed, May 19, 2004 at 12:30:42PM -0700, Tim Bird wrote:
> What on earth are you talking about?  CELF includes members who
> sell things, but the specification specifically discounts any
> claims of conformance.  

Perhaps not, but it uses the language of conformance:

	The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
	SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
	interpreted as described in [RFC2119]. The term "CELF-conforming" is
	used to refer to technology, platforms, or systems that conform to the
	CELF specifications or standards contained in this document.

And in section 3.8.3, it states:

	The Linux kernel SHALL support a configuration to provide the
	following described timing API.

Oh, it SHALL provide such a API, shall it?  Says who?  Does the CELF
really think to dictate to the kernel developers that they SHALL use a
particular API?  Language such as this can really rub people the wrong
way, especially when they don't have the authority to make such
demands on the kernel development community.

Something a lot more informal, such as, "look we really could use the
following facility".  Here's a suggested API; we're not wedded to it,
but this is why we need the following functionality.  Currently, the
rationale/justification is currently completely missing for section
3.8.2 for this feature.  We are just told that we MUST and SHALL
provide this feature, for no good stated reason:

A) The configuration option to enable this feature MUST be called
CONFIG_FAST_TIMESTAMPS

B) When CONFIG_FAST_TIMESTAMPS is enabled, the kernel SHALL provide
the following 2 routines:

      2.1 void store_timestamp(timestamp_t *t)

      2.2 void timestamp_to_timeval(timestamp_t *t, struct timeval *tv) 

etc.

I think the reason why some folks might suspect that consortia such as
CELF might be bilking their members is because such a document might
easily be construed by a pointed-haired-boss that CELF might actually
have the authority to dictate demands to the Linux Kernel development
community.

Would it not be more honest to admit freely that each one of these
wishlist items involve a negotiation process, and the ultimate API
might be different --- in some cases perhaps more restricted, or in
other cases, in collaboration with the kernel development community,
it might be that a more powerful, more general API that solves several
problems might be devised?

In any case, having discussion in closed forums can very often be a
waste of time, since the discussions will then have to be replicated
in the open forums --- in the case of linux kernel, in LKML --- before
the discussions will actually do any good.  I suppose for less
confident folks, they could view CELF as a practice forum, or perhaps
it is a way of anonymizing requests from people who don't want to
admit that they are using Linux, or who don't want to admit they need
a particular request.  They should be aware, however, that anonymous
requests often get less weight than specific requests that explain
specifically why a particular feature is needed.

And definitely, an approach which is more collegial and less
dictorial, which doesn't explain why the kernel developers MUST and
SHALL do is much more likely to succeed.  You catch few flies with
vinegar.

Just a few friendly suggestions....

							- Ted

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Tim Bird]

Theodore Ts'o wrote:
> On Wed, May 19, 2004 at 12:30:42PM -0700, Tim Bird wrote:
> 
>>What on earth are you talking about?  CELF includes members who
>>sell things, but the specification specifically discounts any
>>claims of conformance.
> 
> Perhaps not, but it uses the language of conformance:
> 
> 	The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
> 	SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
> 	interpreted as described in [RFC2119]. The term "CELF-conforming" is
> 	used to refer to technology, platforms, or systems that conform to the
> 	CELF specifications or standards contained in this document.

Ted,

I completely agree with everything you say here, and I want
to clarify and correct any misunderstandings.

The reason conformance language is used is because, well,
specs. use conformance language to indicate levels of interest.

The primary audience for the specification (as indicated in
the introduction) is CE member company developers - NOT
community kernel developers.

> And in section 3.8.3, it states:
> 
> 	The Linux kernel SHALL support a configuration to provide the
> 	following described timing API.
> 
> Oh, it SHALL provide such a API, shall it?  Says who?  Does the CELF
> really think to dictate to the kernel developers that they SHALL use a
> particular API?
Absolutely not.  Despite the conformance langauge, the specs
are intended to be quite mutable in the context of a dialog
with community kernel developers.  Please note that there are
hundreds of kernel developers at these CE companies who are
not involved with the community at all.  We're trying to bridge
that gap where possible.

> Language such as this can really rub people the wrong
> way, especially when they don't have the authority to make such
> demands on the kernel development community.
I can see how this would be interpreted so.  I'll look
for a way to make documents interchanged with the community
avoid the possibility of such an interpretation.

> Something a lot more informal, such as, "look we really could use the
> following facility".  Here's a suggested API; we're not wedded to it,
> but this is why we need the following functionality.  Currently, the
> rationale/justification is currently completely missing for section
> 3.8.2 for this feature.
Dang. This is a MAJOR oversight.  This is supposed to be there, and
is more important in the context of this discussion than the
Specifications section.

I'll fix this pronto.

As for the formality issue, I'll look for a way to word
communications with the community so that there is no
implication of inflexibility.

> We are just told that we MUST and SHALL
> provide this feature, for no good stated reason:
> 

In the mean time, some background rationale for this is contained
on the page:
http://tree.celinuxforum.org/pubwiki/moin.cgi/InstrumentationAPI
(This page is out of date, but it has some information to provide
context for the requirement.)

> I think the reason why some folks might suspect that consortia such as
> CELF might be bilking their members is because such a document might
> easily be construed by a pointed-haired-boss that CELF might actually
> have the authority to dictate demands to the Linux Kernel development
> community.
I hope we can avoid that.  You'll have to take my word for it, but
NO ONE of the member companies has ever been told that we have the
power to dictate demands to the Linux development community.
Quite the contrary.

We even have a few special members (Greg Ungerer and Karim Yaghmour)
who are community developers themselves, and who we hope
can vouch for our intentions (at least from what they've seen.)
We invited these guys to join us in part to keep us "honest" with
the community.

> Would it not be more honest to admit freely that each one of these
> wishlist items involve a negotiation process, and the ultimate API
> might be different --- in some cases perhaps more restricted, or in
> other cases, in collaboration with the kernel development community,
> it might be that a more powerful, more general API that solves several
> problems might be devised?
Yes, I freely admit that each of these wishlist items involves
a negotiation process.  As is always the case with Linux, if
we have features that no one else wants, and the kernel development
community has no interest in - then if we must have them we'll
maintain them ourselves.  Nothing new here.

Here's some honesty which I don't think you'll hear from
anyone else.  The lack of control is part of the
reason the forum exists.  For stuff that the community won't
accept (and there will be some), it's nice to have a centralized,
controllable entity which manages such things.  A Linux vendor
doesn't quite fit the bill here.

So you see, the existence of the forum is in part an ACKNOWLEDGEMENT
of our inability to dictate the direction of Linux.

Finally, we fully expect that collaboration with the community
will produce much better results than we could come up with
ourselves.

> In any case, having discussion in closed forums can very often be a
> waste of time, since the discussions will then have to be replicated
> in the open forums --- in the case of linux kernel, in LKML --- before
> the discussions will actually do any good.
Agreed.  However, there are legitimate business reasons for
conducting some activities in private.  Also, believe it or not, but
one reason we've historically been so quiet is to avoid bothering
LKML with issues before we've researched them out.  Perhaps we've
erred on the side of quietness, but it's very difficult to gauge
when to come to LKML with an issue.  You can get flamed for
being unprepared, as well as for being overprepared.  Since
we've been primarily working on 2.4, we've felt very sheepish
about entering the fray on LKML on specific issues.

> I suppose for less
> confident folks, they could view CELF as a practice forum, or perhaps
> it is a way of anonymizing requests from people who don't want to
> admit that they are using Linux, or who don't want to admit they need
> a particular request.  They should be aware, however, that anonymous
> requests often get less weight than specific requests that explain
> specifically why a particular feature is needed.
We didn't mean to omit the explanation for the timing api request.
It's not even a "request" to kernel.org.  We try not to do that.

> 
> And definitely, an approach which is more collegial and less
> dictorial, which doesn't explain why the kernel developers MUST and
> SHALL do is much more likely to succeed.  You catch few flies with
> vinegar.
> 
> Just a few friendly suggestions....

I deeply appreciate your taking the time to make them.
I will take measures to correct the problems you identified
and try to avoid making them again in the future.

Thanks,

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

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Tim Bird]

Christoph Hellwig wrote:
> On Mon, May 17, 2004 at 12:05:36PM -0700, Tim Bird wrote:
> 
>>I am writing to announce the availability of the first draft of
>>the CE Linux Forum's first specification.  This specification
>>represents the efforts of six different technical working groups
>>over about the last 9 months.
> 
> 
> If you want my 2Cent:
> 
>  - stop these rather useless specifications and provide patchkits instead
>  - try to actually submit the patches upstream to get a feeling which
>    of your 'features' are compltely hopeless, which are okay and which
>    can better be solved in different ways.

I should point out that some of the features specified have already been
submitted as patchsets.  Some were accepted and are in 2.6.  Some were
rejected, and we are considering the feedback received...  (But, we're
still hopeful that in the long run, we can make certain things
acceptable for inclusion in the mainline tree.)

The submissions, so far, have come from member companies or individuals
rather than from the forum itself.

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

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Adrian Bunk]

On Mon, May 17, 2004 at 02:22:29PM -0700, Tim Bird wrote:
> Christoph Hellwig wrote:
> >On Mon, May 17, 2004 at 12:05:36PM -0700, Tim Bird wrote:
> >
> >>I am writing to announce the availability of the first draft of
> >>the CE Linux Forum's first specification.  This specification
> >>represents the efforts of six different technical working groups
> >>over about the last 9 months.
> >
> >
> >If you want my 2Cent:
> >
> > - stop these rather useless specifications and provide patchkits instead
> > - try to actually submit the patches upstream to get a feeling which
> >   of your 'features' are compltely hopeless, which are okay and which
> >   can better be solved in different ways.
> 
> I should point out that some of the features specified have already been
> submitted as patchsets.  Some were accepted and are in 2.6.  Some were
> rejected, and we are considering the feedback received...  (But, we're
> still hopeful that in the long run, we can make certain things
> acceptable for inclusion in the mainline tree.)
> 
> The submissions, so far, have come from member companies or individuals
> rather than from the forum itself.

A good example that this is true is section 7.9.2 of your 
"specification".

It lists under "Work in Progress":
  Kernel SHALL be configuralble with compiler size options, such as -Os.

Besides the text in the "Rationale" being obviously wrong, this is 
already implemented in kernel 2.6. But the people writing this
"specification" didn't send a patch - the trivial patch was sent by 
someone who is in no way related to your "Forum".

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Tim Bird]

Adrian Bunk wrote:
> On Mon, May 17, 2004 at 02:22:29PM -0700, Tim Bird wrote:
>>Christoph Hellwig wrote:
>>>If you want my 2Cent:
>>>
>>>- stop these rather useless specifications and provide patchkits instead
>>>- try to actually submit the patches upstream to get a feeling which
>>>  of your 'features' are compltely hopeless, which are okay and which
>>>  can better be solved in different ways.
>>
>>I should point out that some of the features specified have already been
>>submitted as patchsets. 
 >
> A good example that this is true is section 7.9.2 of your 
> "specification".
> 
> It lists under "Work in Progress":
>   Kernel SHALL be configuralble with compiler size options, such as -Os.
> 
> Besides the text in the "Rationale" being obviously wrong, this is 
> already implemented in kernel 2.6. But the people writing this
> "specification" didn't send a patch - the trivial patch was sent by 
> someone who is in no way related to your "Forum".

First, I'll point out that this spec, as you noted, is still
a work in progress.

Yes, the rationale is wrong.  Thanks for pointing that out.
I'll get it fixed before we release a spec on this.  We have
a separate agenda item in our size working group to look at
inline expansions (See section 7.9.3 where it lists candidate
projects that are not started yet.) There is already valuable
work going on in the area of inline reduction, but
unfortunately, we don't have anything to contribute to that
discussion yet.

As for the patch, you are correct that the kernel makefile system
supports compilation with -Os, and someone besides us submitted
the patch for that.  However, there is more work needed to
validate that the option doesn't break things, on many different
architectures.

I have reports from the uClinux crowd that use of
the -Os option is fairly typical for users of uClinux, and they
have no reports of breakage.  However, we want to take a methodical
approach to validating that use of this option is fully supported
by the Linux kernel.  Also, we want to test and report the size
and performance effects of the use of the flag.  This work is
not done yet, so the spec. is still under construction.

Just jamming in the compiler option is not really what we intend here.
I'll try to make sure this spec., when released, is worded to
express our requirement that the option be meaningful and safe,
rather than just supported by the build system.

If you see patches from us (or one of our members) related to this spec.,
they will be to fix issues where use of -Os breaks something in the kernel.

Thanks for the feedback.  We'll keep working on this one.

P.S. Why is "Forum" in quotes?

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

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Adrian Bunk]

On Wed, May 19, 2004 at 09:59:08AM -0700, Tim Bird wrote:
> 
> First, I'll point out that this spec, as you noted, is still
> a work in progress.
> 
> Yes, the rationale is wrong.  Thanks for pointing that out.
> I'll get it fixed before we release a spec on this.  We have
> a separate agenda item in our size working group to look at
> inline expansions (See section 7.9.3 where it lists candidate
> projects that are not started yet.) There is already valuable
> work going on in the area of inline reduction, but
> unfortunately, we don't have anything to contribute to that
> discussion yet.

The main problem seems to be that you write much paper instead of 
simply writing and testing code.

Your approach might be a good solution for big projects, but if the 
changes are relatively simple it's not very useful.

> As for the patch, you are correct that the kernel makefile system
> supports compilation with -Os, and someone besides us submitted
> the patch for that.  However, there is more work needed to
> validate that the option doesn't break things, on many different
> architectures.
> 
> I have reports from the uClinux crowd that use of
> the -Os option is fairly typical for users of uClinux, and they
> have no reports of breakage.  However, we want to take a methodical
> approach to validating that use of this option is fully supported
> by the Linux kernel.  Also, we want to test and report the size
> and performance effects of the use of the flag.  This work is
> not done yet, so the spec. is still under construction.
>...

If you'd have asked people knowing the code (e.g. by sending an email to 
linux-kernel), you'd have already known:
- the ARM port always uses -Os in kernel 2.4
- the ACPI code is always compiled with -Os in kernel 2.4
- part of the ARM port always uses -Os with "recent" gcc in
  kernel 2.2

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Tim Bird]

Adrian Bunk wrote:
> The main problem seems to be that you write much paper instead of 
> simply writing and testing code.

The specification you refer to consists of 4 sentences.  One
of them was normative.  The main goal is to communicate to
linux vendors and silicon vendors that CE companies are
interested in correct support of this option.  For the
platforms and code where this is not the default now, there
is a risk that -Os bugs might cause problems.

> Your approach might be a good solution for big projects, but if the 
> changes are relatively simple it's not very useful.

Verifying that something is supported correctly on multiple
architectures is not simple.  Yes, we know that the default
optimization level for ARM is -Os.  As recently as last month,
there was a problem report about -Os on the gcc mailing list.

I fail to see what it is about our communication (that we'd like
to see all platforms support -Os) that you find so offensive.

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

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Nicolas Pitre]

On Wed, 19 May 2004, Tim Bird wrote:

> Verifying that something is supported correctly on multiple
> architectures is not simple.  Yes, we know that the default
> optimization level for ARM is -Os.  As recently as last month,
> there was a problem report about -Os on the gcc mailing list.

Incidentally, with all gcc-3.* in existence today, the kernel gets
miscompiled if -Os is not used on ARM due to a gcc bug.  But this is not the
reason why -Os was chosen as default on ARM though.


Nicolas

Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft

[Russell King]

On Wed, May 19, 2004 at 09:59:08AM -0700, Tim Bird wrote:
> As for the patch, you are correct that the kernel makefile system
> supports compilation with -Os, and someone besides us submitted
> the patch for that.  However, there is more work needed to
> validate that the option doesn't break things, on many different
> architectures.

Well, on ARM, building with anything other than -Os shows up
compiler bugs in the gcc3 toolchain, so here the only option
is to use -Os.

I guess you can say that means ARM is validated for building
with -Os but not -O2 with 2.6.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core