Subject: Re: NetBSD 1.4N/pmax not bootable on 5000/133
To: Toru Nishimura <nisimura@itc.aist-nara.ac.jp>
From: Simon Burge <simonb@netbsd.org>
List: port-pmax
Date: 11/19/1999 15:03:58
Toru Nishimura wrote:

> >> There is a premitive error in the case analysis. || should be &&.
> >
> > I've just "cvs update"d, and still have a problem on my headless 3100.
> > You haven't included "opt_dec_{3,5}100.h" in ibus_pmax.c, so the code in
> > ibus_pmax_attach is never called!  I also needed to fix the prototypes
> > of dec_3100_intr_establish() and dec_3100_intr_disestablish() [**].  I've
> > just committed this now.
> 
> Doh, I will fix it.

In case it wasn't clear, I've got it back to compiling stage, and I can
boot my 3100 now.

> Simon.
> 
> > [**] - Over time, I'd like to have no extern function declarations
> >       in any .c files, only in .h files.  This will help make sure that
> >       prototypes are always correct...  For the interupt functions,
> >       would pmax/kn01.h, pmax/kn230.h, etc be the right place for
> >       these declarations?
> 
> You have the point about prototype declarations.  I think it's not a
> nice practice to C declarations (struct's, function prototypes, and
> others) in kn01.h/kn230.h.  Such files, like as *reg.h, should be the
> design and defition of the particular hardwares.  OS implementations
> peculiar to specific approachs should go into *var.h.
> 
> I think they should have been declared inside ibusvar.h.

I wonder if it might be better to add the ibus interrupt functions to
'struct platform' instead?  Of course, on most machines this will not be
assigned...

Also, unless you're familiar with model numbers, it seems confusing to
have a "dec_3100.c" and a "kn01.h".  I'm not sure what to think about
this one!

> >> I will remove findcons.c in near future. 
> >
> > I'll look at your changes for this soon!
> 
> I'm reducing interlocked dangleweeds in NetBSD/pmax hoping it would
> ease adding new DECstation hardwares, 5400/5500/5800.  Basically it'd
> be just ok to have dec_{5400,5500,5800}.c in pmax/ directory.  'ibus'
> construtor can support 'Q22bus' and/or 'XMI' having "q22" or "xmi"
> identification string in platform.iobus and preparing others so-so.

Adding more things to 'struct platform' will also reduce external
function assignments too...

Simon.