Messages in this thread | | | Date | Thu, 04 Jul 2002 10:36:23 +0200 | From | Mike Galbraith <> | Subject | Re: [OKS] Module removal |
| |
At 08:04 AM 7/2/2002 -0400, Richard B. Johnson wrote: >On Tue, 2 Jul 2002, Stephen C. Tweedie wrote: > > > Hi, > > > > > The suggestion was made that kernel module removal be depreciated or > > > removed. I'd like to note that there are two common uses for this > > > capability, and the problems addressed by module removal should be > kept in > > > mind. These are in addition to the PCMCIA issue raised. > > > > > 1 - conversion between IDE-CD and IDE-SCSI. Some applications just work > > > better (or usefully at all) with one or the other driver used to read > CDs. > > > > The proposal was to deprecate module removal, *not* to deprecate > > dynamic registration of devices. If you want to maintain the above > > functionality, then there's no reason why a device can't be > > deregistered from one driver and reregistered on another while both > > drivers are present. Note that the scsi stack already allows you to > > dynamically register and deregister specific targets on the fly. > >As I am led to understand from reading this thread, there is some >known bug caused by module removal. Therefore the "solution" is to >remove module removal capability.
Read the thread more carefully, and you'll understand more than "some known bug". Heck, you may even be able to contribute to a more palatable race solution than depreciating module unload entirely.
>This is absurd. Next, somebody will remove network capability because >there's some bug in it. Hello there........? Are there any carbon- >based life-forms out there?
I'm not absolutely certain that those life-forms discussing options are carbon-based ;-) but they have demonstrated considerable knowledge of the subject IMO.
-Mike
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |