Subject: Re: ca_activate et al
To: Jachym Holecek <>
From: Bill Studenmund <>
List: tech-kern
Date: 06/29/2006 18:38:10
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 =
> > thread).
> 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=
interrupt context. We then can (and should) have another detach call which=
happens in a thread context.

We have two conflicting needs. We need to tell the devices to stop working=
ASAP, which means we need to tell them in interrupt context. We also need=
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,


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

Version: GnuPG v1.2.3 (NetBSD)