On Mon, Jan 30, 2006 at 08:51:44PM -0800, Garrett D'Amore wrote:

> Simon Burge wrote:
> > On Mon, Jan 30, 2006 at 02:49:26PM -0800, Garrett D'Amore wrote:
> >
> >   
> >> Good.  What I will do is go ahead and commit *that* change seperately,
> >> and then commit the PCI code which depends on it after I have changed
> >> it. :-)
> >>
> >> Any objections (Simon?)  Speak up now, please!
> >
> > My first broad comment on the PCI-specific parts was the name of the
> > device (aupb) - I would have preferred aupci, or at a stretch aupcib
> > to keep in line with the current naming conventions.  There was a stub
> > entry already in the aubus attachment code for aupci.
> >   
> I think I forgot to respond to this one earlier.  Sorry 'bout that.  I
> actually prefer the name aupci myself, but I decided to use aupb in a
> (perhaps foolish) attempt to follow the standards set by other ports. 
> There were two choices to follow: XXpb (where "pb" presumably means "pci
> bridge"), or some name that doesn't reflect PCI at all (e.g. galileo or
> bonito), and then a "device node" (not sure about NetBSD terminology
> here) that is "pci".  (E.g. a lot of platforms have a "pci" device that
> is not backed by a "pci.c" file, and which is totally different from
> platform to platform.)
> 
> I'm more than happy to change aupb to aupci if that is preferable. 
> After all, its just a name, and "pci" is more descriptive.  I would like
> to avoid having to rename all the internal symbols for now, if possible,
> but that's just because I'm lazy and there are a bunch of them.  (I
> don't trust a global search/replace not to bodge something else.)
> 
> Anyway, let me know which you want, and whether it is a blocker for
> commit, and I'll do whatever.

It seems that the split between foopb and foopci, and even foopcib,
is all over the shop.  I still prefer aupci myself.  Just changing
the filename and the CFATTACH_DECL name (and obviously the kernel
config file bits) is enough for now I think.  We can easily rename
the internal functions later on.

I'll get back to you with some other comments on the non-PCI parts of
that patch (the CPU support split up, etc) soon.

Simon.
--
Simon Burge                                   <simonb@wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/