Izumi Tsutsui wrote:
> garrett_damore@tadpole.com wrote:
>
>   
>> Boy, was I wrong:  isa/ast.c is the first place (and I think there may
>> be at least on other) where the driver includes comvar.h, but also has
>> its own sc_iot.  Needless to say, this breaks things badly. 
>>     
>
> How many files have the problem?
>   
A few.  At this point I'm going to go with my gut and say "macros are
evil", and avoid it.
The name "sc_iot" is just too easily hit upon.

> In ast.c case, I think you could change ast_softc to use
> struct com_regs since it requires the relevant stuff to com_softc.
>   

I disagree.  See my comments above.

>   
>> Unfortunately I got halfway thru the conversion before I found the problem.
>>     
>
> Well, maybe ~two hour silence is not enough
> (I see your second mail after a sleep) and
> it's not so good for you to be in a rush so much
> on such large changes... ;-)
>   

Well, I don't want to have this sit in a branch forever.  I actually
tried to be compliant and make the changes you suggested, but got bit in
the ass.

At this point, I'm going to stand my ground, I think.  Of course, core@
can always make the final decision. :-)

> As I wrote before, not all people have enough spare time
> to review code and think any other good idea.
> We might be able to get some other choice after a few days...
>   

The problem is I had this conversation on tech-kern months ago.  It
bike-shedded.  Now I want to get it *done*.

    -- Garrett
> ---
> Izumi Tsutsui
>   


-- 
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