John Baldwin wrote: > On Wednesday, July 14, 2010 2:35:48 pm Alexander Motin wrote: >> John Baldwin wrote: >>> On Wednesday, July 14, 2010 1:01:14 pm Alexander Motin wrote: >>>> John Baldwin wrote: >>>>> On Wednesday, July 14, 2010 11:59:46 am Alexander Motin wrote: >>>>>> John Baldwin wrote: >>>>>>> On Wednesday, July 14, 2010 9:31:27 am Alexander Motin wrote: >>>>>>>> Author: mav >>>>>>>> Date: Wed Jul 14 13:31:27 2010 >>>>>>>> New Revision: 210054 >>>>>>>> URL: http://svn.freebsd.org/changeset/base/210054 >>>>>>>> >>>>>>>> Log: >>>>>>>> Move timeevents.c to MI code, as it is not x86-specific. I already >>>>>>>> have >>>>>>>> it working on Marvell ARM SoCs, and it would be nice to unify timer >>>>> code >>>>>>>> between more platforms. >>>>>>>> >>>>>>>> Added: >>>>>>>> head/sys/kern/timeevents.c >>>>>>>> - copied unchanged from r210053, head/sys/x86/x86/timeevents.c >>>>>>>> Deleted: >>>>>>>> head/sys/x86/x86/timeevents.c >>>>>>>> Modified: >>>>>>>> head/sys/conf/files.amd64 >>>>>>>> head/sys/conf/files.i386 >>>>>>>> head/sys/conf/files.pc98 >>>>>>> Can this be merged with kern_et.c, >>>>>> They are different. kern_et.c provides event timer drivers API, >>>>>> timeevents.c consumes it to manage kernel clocks. kern_et.c >>>>>> theoretically can be used without timeevents.c if some other code >>>>>> consume timers, for example, exposing them to user-level. >>>>>> >>>>>> May be names indeed cryptic a bit, but I had no better ideas. >>>>>> >>>>>>> or perhaps called subr_eventtimers.c instead? >>>>>> Whatever you like, but why exactly so and why "subr_" important? >>>>> The vast majority of files in sys/kern use some sort of prefix, either >>>>> sys_*, >>>>> kern_*, subr_*, etc. subr_ was just a suggestion to avoid clashing with >>>>> kern_et.c. If timeevents.c is specific to clocks then maybe it should >>>>> have >>>>> 'clock' in its name somehow? Right now having kern_et == >>>>> kern_eventtimer.c >>>>> and timeevents.c is a bit ambiguous. Somehow making it clear that >>>>> timeevents.c is for clocks might help. >>>> We already have kern_clock.c and subr_clock.c. kern_clock.c is quite >>>> close by meaning. What's about kern_clocksource.c? >>> Ok. I assume it would not be easy to just merge this file into kern_clock.c >>> itself? >> At least not until all architectures will adapt to it. > > Do you think that is the long term goal?
I think not, but timer code for the many arches need to be refactored, all of them are different and some I've never seen. > If so, you could put this code into > kern_clock.c and selectively enable it with a macro defined in > <machine/param.h> as a temporary measure until all platforms have adopted it. That's possible, but I am not sure it is reasonable. -- Alexander Motin _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "[email protected]"
