> 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