--Fe0dstq7l4iXK2TV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 18, 2006 at 11:27:06AM -0600, Peter Seebach wrote:
> So, I'm starting on the NAND stuff.  And some of this is easy and obvious.
>=20
> Some of it isn't, and I'm guessing there's some essential element of the
> organization here I don't get.
>=20
> I basically follow the struct cfattach.  What I don't understand is why
> the struct cfattach objects are declared in such very odd ways.  For inst=
ance,
> consider the 15-line macro that declares, indirectly, "usb_ca":
>=20
> 	#define USB_DECLARE_DRIVER(dname)  \
> 	[...]
> 	const struct cfattach __CONCAT(dname,_ca) =3D { \
> 		sizeof(struct __CONCAT(dname,_softc)), \
> 		__CONCAT(dname,_match), \
> 		__CONCAT(dname,_attach), \
> 		__CONCAT(dname,_detach), \
> 		__CONCAT(dname,_activate), \
> 	}
>=20
> So, what I'm not getting is:
>=20
> * Since I can't see any reason for any driver's cfattach not to look like
> this, why is this in a USB header?

USB code does it this way to have common source with other BSDs.  Plain
NetBSD drivers use CFATTACH_DECL().

> * Am I right in thinking that it's actually config that will generate a t=
able
> that includes the reference to usb_ca?

Yes.

> More generally, the procedure by which devices get into cdevsw is not obv=
ious
> to me; for instance, where is the information used to decide where rnd_cd=
evsw
> goes?  I can't find any reference to rnd in ***/files.*, or in config's
> source.  But obviously it comes from SOMEWHERE.

Look in $ARCH/conf/majors.$ARCH and conf/majors.

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.

--Fe0dstq7l4iXK2TV
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBRBxKcNgoQloHrPnoAQJ/8gf/U0FnsormKK/tC7wUMAzWLGaWkTdc8AXr
y7STSYaG5FmEPFA5iQeCi4RI8/eZCaNyB6kuLtAS/pDDY5C63h/SwlgQvBMop8EI
XbaKeKusgA6Oh2p6V5UbeDsVReFyZ7OVoJbX9G7ODR+zdieYFBBySz17iV9/z9m9
/WQJSkYuMTmn9GeDoeJYbKCALZpogvSJ4DtRixu3j3SPokBqDieYqEkweswUiHah
5VGdSF4+R+YTGcVzVqs7NotN3eL7ixvNMMCR7fYKJClaPe6sJU/DKuqy9Fve5SLX
ROoodgBnN2zWx5MZPCkA+oesduFnv5Xu4ufOfGP0HCgb+LrcD1r8AA==
=Ar0y
-----END PGP SIGNATURE-----

--Fe0dstq7l4iXK2TV--