[U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite

[Graeme Russ <graeme.russ@gmail.com>]

On 12/07/11 09:36, Graeme Russ wrote:
> On 12/07/11 07:56, Wolfgang Denk wrote:
>> Dear Graeme Russ,

[snip]

>> Having this still in mind, I took a look across the fence to what
>> barebox is doing.  Guess what?  From "common/clock.c":
>>
>> 	 * clock.c - generic clocksource implementation
>> 	 *
>> 	 * This file contains the clocksource implementation from the Linux
>> 	 * kernel originally by John Stultz
>>
>> OK.  Message received.
> 
> Yes, and barebox is also pulling in slabs of other Linux code such as
> driver framework etc. I think you will find barebox will ultimately have a
> very large code-base and binary image because of that. I think that U-Boot
> and barebox are heading in two different directions (and so they should,
> what would be the point otherwise) - barebox will become modular but
> larger, U-Boot will continue to be homogeneous and small.
> 
>> What I'm asking myself (and now you) is: Should we really re-invent
>> the wheel again?
> 
> OK, I've now had a brief look and I have the following comments:

[snip]

OK, now I've had a look at the Linux code (\kernel\time\*) and Barebox
(http://git.pengutronix.de/?p=barebox.git;a=blob;f=common/clock.c;h=79c06c8ddc1b3f447f7c81bf8bb592458f895ab3;hb=HEAD)
I think I can safely say that:

a) We do not want to inherit the code from Linux. It's good code clean
code, but it is just way too much for what we need. It handles registering
and unregistering clock sources, change clock source 'rating' (what ever
that is) and relies heavily on quite heavy (for U-Boot) struct's (which may
need to be carted around in Global Data)
b) Barebox doesn't really inherit that much from Linux anyway

I think we have the basics right (and that is the same as Linux). We just
need to settle on a few finer points such as:

 - Raw time interval. Linux uses nanoseconds. A 64-bit nanosecond clock
   source goes for >580 years so even if the highest resolution clock
   available to us right now is microsecond, it will not hurt to go with a
   nanosecond time-base as that will provide us with the greatest
   flexibility going forward. However, this will lead to a lot of integer
   divides and/or multiplies to scale to millisecond and microsecond
   intervals
 - Function naming
 - Performing time comparisons for timeouts - Barebox for example has a
   is_timeout function which takes a start time and a delay (in
   nanoseconds) an implements ndealy, udealy, and mdelay using is_timeout

I think what has been proposed here recently and documented (slightly
out-of-date) on the wiki is the way to go. Taking the Linux or Barebox
source will be more effort than it's worth for the complexity it brings in.

I recall an apt quote 'Good programmers know when to re-use, great
programmers know when to re-write'

Regards,

Graeme