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?
Leal. 2008/5/20 James Carlson <[EMAIL PROTECTED]>: > Marcelo Leal writes: >> I just want to ask you about the installation of kernel patches on >> opensolaris/solaris... >> opensolaris(solaris) is the more modular kernel that i know about, and i >> think that is a really good thing (thinking about all the features that such >> configuration has, like updates). But, seems like the procedure to apply a >> update without shutdown the server, is not the "standard" way, because >> install a solaris kernel patch is much like install a windows service pack >> (you need to reboot the server and cross the fingers). >> I think opensolaris have not kernel updates, because here is the project >> site, and i don't know how the updates will be handled by OpenSolaris >> distribution, but here we have the engineering for the product... so, i ask: >> the modular kernel should not be for make more easy the modules' fix? > > You've asked a somewhat complicated question. > > First, yes, the kernel is modular. And it certainly is possible to > unload a kernel module and insert a replacement on a running system > without rebooting. > > Not all modules can do this, though. In order to unload a kernel > module, you have to be able to shut down all references to that module > -- delete all internal state, close all open descriptors, disable all > callbacks and timers, and so on. How you do that depends entirely on > the module itself; there is no one mechanism. Some modules are > written such that their _fini(9E) entry point aways returns an error; > they can never be unloaded, because the designer of the module didn't > figure out how to make it unloadable. > > The other part of your question has to do with patches. Patches are > collections of sparse packages. They are crafted as part of the > update creation process. The normal development process, though, does > *NOT* create patches. There are no patches for Nevada or > OpenSolaris. Instead, new full packages are built each time, and you > must upgrade between builds. > > -- > 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 > > -- pOSix rules _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
