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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
