Andrew Morton wrote: > Elias Kesh <[EMAIL PROTECTED]> 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 ============================= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
