Return to BSD News archive
Newsgroups: comp.os.386bsd.misc Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!saimiri.primate.wisc.edu!sdd.hp.com!col.hp.com!csn!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: BSD/386 Commercial Product Message-ID: <1993Jul29.202234.24664@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University, Ogden, UT References: <1993Jul28.025606.6655@spcvxb.spc.edu> <23782b$1vo@pdq.coe.montana.edu> <1993Jul29.045217.28165@wlbr.iipo.gtegsc.com> Date: Thu, 29 Jul 93 20:22:34 GMT Lines: 53 In article <1993Jul29.045217.28165@wlbr.iipo.gtegsc.com> sms@WLV.IIPO.GTEGSC.COM (Steven M. Schultz) writes: > Not necessarily. Much of the time you end up rebooting anyway > because the load/unload part of the driver is broken or buggy - > especially if the driver is currently "running". At least that's > how it was on RSX-11, IAS, etc. "unload" - oops, gotta reboot > anyhow... Then there was the time the tty driver got unloaded > midstream - kinda hard to type a new command to load the new one ;-) Use a shell script. 8-). Actually, the driver is permitted to veto the unload if it's in use. For instance, If I am tring to replace a streams driver, it would be bad form to remove the IP driver while TCP was using it. The LKM package, as distributed by me and ammended by Chris Demetriou (man pages, new VM update, and security fixes to allow non-priveledged users to use the "modstat" command to get a module inventory) in the NetBSD-current tree supports the idea of "unload veto". It would actually be a simple hack to allow unloading to be "queued" by way of entry/exit reference counts and registration of the unload function in the unload entry point if the count was non-zero, triggering it when it goes to zero. This was so trivial I didn't make it an explicit requirement for loadable modules (after all, this is not applicable to all modules, only those that interact with other kernel subsystems above and below themselves. For instance, a veto is sufficient for a loadable file system. One of my intentions is SMP at some time in the future; to do that, you have to acknowledge the possibility of kernel preemption, given that there are multiple concurrent run states which might require reentrancy of many parts of the kernel (most notably the file systems, which are *always* stateful). But there is also the potential that one processer is going into a system call while another processor wants to unload/replace it.. when this occurs, there must be a locking protocol which is obeyed. For a more detailed analysis of the issues involved, look up the following paper (presented at the Summer 1992 USENIX): Beyond Multiprocessing: Multithreading the SunOS Kernel Eykholt, J.R., S.R. Kleiman, S. Barton, R. Faulkner, A. Shivalingiah, M. Smith, D. Stein, J. Voll, D. Williams -- SunSoft, Inc. Proceedings of USENIX, Summer, 1992, p. 11-18 And several of the papers referenced. Loadable module technology is far and beyond the days of the RSX-11; it is actually more mature than you've given it credit for here. Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.