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

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:

	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

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) 


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

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

Just a few friendly suggestions....

							- Ted

  parent reply	other threads:[~2004-05-19 22:09 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
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 [this message]
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).