In message: <[email protected]> John Baldwin <[email protected]> writes: : 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.
Also, subr_ prefix helps prevent collisions in other parts of the tree for files with the same name. Warner _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "[email protected]"
