Subject: Re: ca_activate et al
To: Jachym Holecek <freza@dspfpga.com>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 06/29/2006 18:38:10
--UHN/qo2QbUvPLonB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 27, 2006 at 11:00:25PM +0200, Jachym Holecek wrote:
> # Jason Thorpe 2006-06-27:
> > On Jun 26, 2006, at 7:12 PM, Jachym Holecek wrote:
> > >Unless I'm missing something, "activate" entry points are dead code.
> > >If so, this would be an opportunity to make kernel images somewhat
> > >smaller by removing ca_activate and all related logic.
> >=20
> > No, they're not dead code.  That entry point can be called from =20
> > interrupt context when a device status change is noted on e.g. a =20
> > PCMCIA slot.  It is important to mark the device as "dead" so that =20
> > e.g. an interrupt handler for the device won't try to access its =20
> > registers before the detach entry point can be called (from a kernel =
=20
> > thread).
>=20
> Ah, I misunderstood that, thanks for the explanation. I suppose
> DVACT_ACTIVATE is intented for cases where deactivation reason was
> temporary?

Or if we had policy set (and all the other needed stuff too) such that=20
some devices get frozen immediately, but don't get totally zapped for a=20
while. Yes, this is "later on" kinda stuff, but say if you unplug a NIC=20
and then plug it back in. It'd be nice to get the same struct ifnet and=20
keep all the connections alive on it.

> Still, it doesn't seem right that devices need to handle tree
> recursion themselves. What about moving this to config_[de]activate?
> Similar logic would be useful for powerhooks rework, too.

The problem with consolidating this is that we really have two levels of=20
detach. We have the immediate detach, such as this call, which happens in=
=20
interrupt context. We then can (and should) have another detach call which=
=20
happens in a thread context.

We have two conflicting needs. We need to tell the devices to stop working=
=20
ASAP, which means we need to tell them in interrupt context. We also need=
=20
to do cleanup that, in general, can need to sleep. Thus general cleanup=20
has to be able to sleep.

So we need two levels of cleanup. :-|

Take care,

Bill

--UHN/qo2QbUvPLonB
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFEpICCWz+3JHUci9cRAm8DAJ492Fp8Zu3zHfQ+BNUmiJDag+VyiQCdHN/3
ABz9MRC2XCfzm7t5EbLo+0M=
=dpl/
-----END PGP SIGNATURE-----

--UHN/qo2QbUvPLonB--