Garrett D'Amore wrote:

>Frank Kardel wrote:
>  
>
>>>[...]
>>>      
>>>
>>There are more constructs like that. The time pickup from the RTC chip
>>with the decision whether to use file system time or rtc time could be
>>refactored into MI. MD just needs to provide an RTC reading and
>>setting function.
>>And that could even be refactored by using a device concept to get
>>access to
>>the RTC and thus allow sharing of chip access code. (I don't know
>>whether this is
>>the most pressing topic but it would simplfy ports again)
>>    
>>
>
>Actually, looking at evbmips inittodr(), I think that routine could
>easily be moved.  In fact, I dont' see even one line in that code that
>is port specific.  Not even CPU-specific -- the whole code could
>probably be moved into kern_todr.c or somesuch.
>  
>
yepp - I saw many ports that just need to provide a function return
the wall clock time and everything else could be shared. The is quite
a bit duplication going on and also some confusing when to set
the rtc. The MI code knows a variable time_adjusted to indicate that
the rtc needs to be set upon halt/boot. MD parts only partly know
about that and others have their own variables (e.g. sparc_time_is_ok
for sparc). So I have the impression that RTC setting may not
always agree with the the MI state.

>Of course, it does require ports (RTCs) to use the TODR set up.  But
>this would move some code out of ports.  (My version in evbmips also
>deals with the case where no RTC is present, which does occur for some
>real hardware.)
>
>  
>
Yes the TODR interface seems to exists in some ports but it was never 
completed
across all ports and so no MI layer has ever been completed.

>Now as far as the MD implementation of delay() and cpu_initclocks(), and
>by association the clock interrupt handler in interrupt.c, that stuff
>could easily be refactored for ports that share a MIPS3 COP0
>implementation.  (I.e. pretty much any modern MIPS machine.)
>  
>
seconded.

>But doing so might require adding a call frame to the interrupt handling
>logic for the clock interrupt (it is currently in-lined) or macro ugliness.
>
>  
>
How bad is it to add another frame? calling hardclock() will add a frame 
anyway.
I think we are getting close to the conflict of "common 
abstraction/maintenability(sp?)"
and "very efficient implementation/support old/low powered hardware".

>And then there is the question of how do you enable this partially? 
>  
>
I don't see the problem yet. ports not using the common code just
implement the things directly (without additional call frames etc.).

>'Cause I don't want to convert all ports -- I'm just not going to do
>that.  I don't have hardware for any MIPS other than evbmips. :-)
>
>  
>
Well, I would just start the common code and convert the ones I can. Then
I would write up a description what needs to be done the clean up other 
ports
and send that out - just the thing I am trying to do with timecounters. Do I
miss a technical issue here ?

Frank