public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tim Bird <tim.bird@am.sony.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux@kesh.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] RealTimeSync Patch
Date: Fri, 15 Jul 2005 11:39:02 -0700	[thread overview]
Message-ID: <42D802C6.2010401@am.sony.com> (raw)
In-Reply-To: <20050714171052.362f93dd.akpm@osdl.org>

Andrew Morton wrote:
> Elias Kesh <linux@kesh.com> wrote:
>> Looking at the archives I see that a an intel patch
>> was submitted back in October but I am unable to
>> determine what the resolution was.
> 
> What patch was that?

http://lkml.org/lkml/2004/10/29/332

> OK.  But adding fiddle new config options and ifdefs is really, really a
> last resort.  Much better to fix the code by making it smarter, or
> runtime-selectable, or by avoiding the delays if we see that they're not
> really needed (like: certain hardware isn't present) or whatever.

...
> Better would be to work out whether the underlying platform really, realy
> needs the delay and if so only enable it on those platforms, preferable via
> a runtime decision.
> 
> But then, I don't know what that synchronisation code is actually trying to
> do.

The short of it: it's trying to make the system
time as accurate as possible, by delaying
setting the system time until the actual RTC
seconds rollover.  Without this synch. operation,
the system time is within a second of the
RTC value anyways.

With regard to the actual feature request,
I agree that a config option should be a
last resort.  I'd rather just eliminate
the synchronization altogether, and let
post-boot code fix the system time
(sub-second) accuracy, if it's needed.
IMHO it won't be needed in embedded
scenarios and will very seldom be needed
in other use areas (server and desktop).
Many desktop users already get their
system time accuracy from an external
source (ntp) now anyways.

We can submit a patch to *remove* code
for multiple architectures very quickly!
;-)

> In general, it's taking waaaay to long to get all
> these CELinux patches into the outside world.  Thanks
> for getting this one on the wires. Let's
> get them all done and finish this thing.

The forum, of late, has been taking a different approach.
While the forum has a few patches we want to push
ourselves directly, we now focus more effort on
getting individual member companies (and individual
engineers) to participate directly in projects
of interest.

As one example, a Sony engineer has participated
quite heavily in the high resolution timers project
over the last year or so.

Only occasionally, when there does not appear
to be another suitable project in an area
(such as fast booting), do we manage a patch
inside the forum and submit it from there.

But I agree that in some areas the forum has
been quite slow to push these patches. This RTC
synch. issue was first discussed on LKML in
May of 2004.

See: http://lkml.org/lkml/2004/5/7/180

In a perfect world, a patch would have shown
up within a week of that discussion.  For
reasons too long to discuss here, it took
5 months instead, and then another 9 months
to submit this.  So, yes, CELF and some
of it's members clearly have some areas
to improve on in working with the open
source model.

I'm sincerely grateful for the help and
encouragement!
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================

  reply	other threads:[~2005-07-15 18:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-14 16:22 [PATCH] RealTimeSync Patch Elias Kesh
2005-07-15  0:10 ` Andrew Morton
2005-07-15 18:39   ` Tim Bird [this message]
2005-07-15  8:05 ` Jan Engelhardt

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=42D802C6.2010401@am.sony.com \
    --to=tim.bird@am.sony.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@kesh.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox