Marcelo Leal writes: > Thanks a lot for your explanation! > I think if this is an area for improvement.. > Maybe the modules itself are not structures "isolated" enough to > provide the load/unload features we want. And, like you said, seems to > be a really complicated procedure to do, isolate a module, and give > it the features needed to handle the communications (needed too) with > the other kernel modules. > I think the possibility to load/unload a kernel module "on the fly", > was a desired feature when the modules were created in the first > place. But seems like that feature is not "reality" in today's > environment. I mean, the complexity today, create almost the same > problem with the "modular" kernel, as the older one had. > Is that right?
It depends on whose reality you're dealing with. For developers working on Solaris kernel modules, it's commonly the case. You just idle your driver, do "modunload -i 0", and insert the new one. Solaris will demand-load the new version on the next reference. For users and administrators, the upgrade code (whether talking about system upgrade via packages or patchs) doesn't know about this feature, and doesn't make much use of it. If you're talking about this latter bit, then you're right that there's more that's needed in order to do more hitless (non-reboot) upgrade, but what's needed isn't _necessarily_ just kernel code. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
