> Jonathan Adams writes:
> > How's that?  Won't patching do a targeted unload,
> which will succeed?
> 
> Right, my mistake, it should.
> 
> Garrett D'Amore writes:
> > Not really.  The clicks and pops come from power
> being applied to 
> > amplifiers, and there's not much you can do about
> it.
> 
> I'd call that more of a hardware design issue.  It
> takes some work to
> avoid letting transients through, but it shouldn't
> just be impossible
> (and I don't think it all should be blamed on
> drivers).
> 
> >     1) modules losing their settings when a
> targetted unload occurs -- 
> > I've argued that if someone is manually unloading a
> module, then this is 
> > appropriate.
> 
> I think it'd be nicer if the settings don't go away
> simply because of
> an unload.  Then you also wouldn't have to reach for
> unusual no-unload
> settings, and you wouldn't have to keep code resident
> in the kernel
> merely to satisfy a desire for some parameter
> storage.

Sounds like one would want a general enough facility to support backwards
compatibility in the face of a replacement version that might have additional
state it wished to save.

Do kstats created by a driver go away when the driver is unloaded, or do they 
stick
around?  (ISTR that they do stick around, but I don't remember where I saw 
that.)

If they do stick around, would it be totally evil to put settings into a kstat 
(if
one didn't mind that anybody could see them)?
-- 
This message posted from opensolaris.org
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to