Subject: Re: mcclock_isa.c unification
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: tech-kern
Date: 03/13/2006 08:23:04
Izumi Tsutsui wrote:
> In article <XFMail.20060313001140.root@garbled.net>
> root@garbled.net wrote:
>
>   
>> (I am not subscribed to tech-kern, so please CC me on replies)
>>     
>
> Well, shouldn't you as a port maintainer? ;-p
>
>   
>> I was looking at mcclock_isa.c on port-prep today, and saw that many other
>> ports had the same file.  Looking at them, they all seem to be essentially the
>> same code, in either different orders, or various stages of bitrot.
>>
>> I'm wondering if there is a technical reason we cannot make a unified
>> mcclock_isa.c, and put it in dev/isa instead?
>>
>> Or am I missing something fundamental about how these are each MD?
>>     
>
> Probe functions could be identical, but attach functions would
> be different because:
>
> - Some of those ports haven't switched to MI todr(9) (and MI mc146818.c)
>   and they still use their own old "struct clockfns" and MD mcclock.c
>   

evbmips falls into this category.  I think this is a good time to start
making the various other ports use todr(9).  Someone is already doing
this for evbmips, I think.

> - The definition of "year of zero" is quite machine dependent
> - Other configuration (BCD/BIN, 12H/24H etc.) could also be different
>
> though the latter of two could be handled by device properties(9).
>   
Yes. 

I like the idea at least of having mcclock_common in dev/ic, and having
bus- or machine-specific attachment code.

    -- Garrett

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191