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

On Sat, Sep 16, 2006 at 09:33:52AM -0700, Matt Thomas wrote:
>=20
> On Sep 16, 2006, at 6:33 AM, Martin Husemann wrote:
>=20
> >On Sat, Sep 16, 2006 at 08:27:44PM +0900, YAMAMOTO Takashi wrote:
> >>	ifnet_specific_key_t ifnet_specific_key_create(void);
> >>	void ifnet_specific_key_destroy(ifnet_specific_key_t);
> >>	void *ifnet_getspecific(struct ifnet *, ifnet_specific_key_t);
> >>	void ifnet_setspecific(struct ifnet *, ifnet_specific_key_t, void =20
> >>*);
> >
> >How about doing something like
> >
> >	prop_dictionary_t dv_properties;/* properties dictionary */
> >
> >in struct device instead? That way we could have an analogon to
> >device_properties(), like ifnet_properties().
>=20
> Only if specifickey won't be used in interrupt mode.  and most network
> stuff is in hard or soft interrupt mode.

Yes & no. What we could do is have the dictionary and have shadow=20
variables. Change the dict, and the shadow variables change too. Think of=
=20
these variables as caching the result of key lookups. While we can't look=
=20
in the dictionary in interrupt context, if we do it right, we _can_ look=20
at the shadow variables. Put another way, as long as we don't do it wrong,=
=20
we can read the shadow variables.

This does mean we need to know when the dictionary changes (as long as the=
=20
driver gets called, not hard). Also, it means that the dictionary can't=20
contain state that needs gathering at interrupt context. Though I doubt=20
anyone would use a properties dictionary for that. :-)

Take care,

Bill

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

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

iD8DBQFFDvVSWz+3JHUci9cRAgaoAKCTHo7sdZkd0GGo2V1et8AF59axHwCffPXQ
8HqhR0UzwcQMDFOS3copAyA=
=t7gf
-----END PGP SIGNATURE-----

--yEPQxsgoJgBvi8ip--