Subject: Re: no callout_stop? Re: callout_init ...
To: Chapman Flack <nblists@anastigmatix.net>
From: Manuel Bouyer <bouyer@antioche.eu.org>
List: tech-kern
Date: 01/05/2006 12:41:42
On Wed, Jan 04, 2006 at 06:23:29PM -0500, Chapman Flack wrote:
> Manuel Bouyer wrote:
> >It's luck. callouts needs to be stopped and freed explicitely before
> >the pointer passed to the callback is freed.
> 
> Ah, kinda what I was thinking. I'm in the process of churning
> out patches to midi right now, so I'll include that.  The callout
> struct doesn't need freed (it's inlined in midi_softc) but should
> definitely be stopped.  Is that usually done in the handler for
> activate/deactivate or for detach?

I don't know off-hand. Is the deactivate handler always called before detach
in case of hot-plug devices like USB ?

> 
> Any thoughts on my earlier question about the placement of
> callout_init?  That seems to be luck too ... I checked and
> saw that callout_init happens to be memset(...0...), and that
> config_attach happens to memset(...0...) the whole softc after
> malloc'ing it, and I'd bet that's the only reason midi_pcppi
> doesn't crash. I wonder how many interesting things would get
> found if config_attach were changed to do memset(...0x5a...) ;)

Well, assuming that the softc is zero'd out when allocated is
valid, and lots of stuff relies on this (I certainly do when writing
drivers). However, assuning that callout_init() is equivalent to memset(0)
is not, this is not part of the interface. Callout have to be explicitely
initialized.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--