API Rewrite
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 16 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 16 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
Quoted 2 lines · Graeme Russ
Quoted 1 line · Wolfgang Denk
Dear Graeme Russ,
[snip]
Quoted 17 lines
Quoted 9 lines
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 StultzOK. 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.
Quoted 4 lines
Quoted 2 lines
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