svn commit: r210054 - in head/sys: conf kern x86/x86

[Alexander Motin]

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