Richard L. Hamilton wrote:
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.)
They do stick around, if one creates them with KSTAT_FLAG_PERSISTENT.
However, its critical that the kstats themselves do not change
structure, or it won't work.
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)?
Its an interesting idea. But kind of ugly, since it is clearly
misusing kstats from what their intended purpose is.
- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
