Subject: pci_intr_evcnt?
To: None <tech-kern@netbsd.org>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: tech-kern
Date: 01/26/2006 17:57:31
--nextPart3768490.Kqi91QbYIT
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I've been perusing the source code, and noticed that I had stubbed out=20
pci_intr_evcnt in my code.

=46urther perusal found that this practice is common.  (See e.g.=20
sparc64/pci_machdep.c, or arc/pci/necb.c which simply leaves the pointer to=
=20
it NULL.)

=46urther examination revealed *no* actual callers of pci_intr_evcnt.

In the man pages, pci(9) refers the user to pci_intr(9) for documentation. =
=20
pci_intr(9) does not have any documentation about it.

I'm thinking that this is routine is cruft that should be purged.  I can't=
=20
imagine exactly how it was intended to be used.

Can we remove this from the API?  Was there some practical reason for=20
explicity having evcnt part of the PCI API that I don't understand?  (Is th=
e=20
idea to be able to map events into some kind of tree struture?  I don't thi=
nk=20
there is currently any mapping done at this layer yet.  (E.g. no way to see=
=20
this relationship: eth0 rx int -> PCI INTA -> ICU IRQ 3 -> CPU INT 0.)=20

Thoughts?

=2D-=20
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

--nextPart3768490.Kqi91QbYIT
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (SunOS)

iQEVAwUAQ9l+EP49Sp1nAoU7AQJ/ugf/T0IBrX67QS2rK1sD+POoI4SQ7sHpLwDF
Cj+x0BOj0lvVMYUa2lHgflh7Z+EJJHHpqINAGgWbSBUV1r8euPlaXiNlhPiAP5NW
MAjMQOWq2sJdyXCb2ovVk58O/wgkUQdzTJsHwOQz5b/mTDWOvwpWeihv5sHASPuI
sn8Q5C0myc5g1a5pQgXJNvt89CAEfmVskxHk1Ae9OXgGlOjB1V/Rr+SzJGbtnBnA
ig6bTszyizk0APU3NJZqwQx+1ZsJOxInUa2hJj21WQ91MohdjTZlTjAH2xsVEufR
E5SAX8dqBRTF8YlOS748kV2TPMky82He1FvjsvfelyRVYSagTT4tMg==
=QXSc
-----END PGP SIGNATURE-----

--nextPart3768490.Kqi91QbYIT--