Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 3 Jul 2002 13:22:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 3 Jul 2002 13:22:32 -0400 Received: from chaos.analogic.com ([204.178.40.224]:10880 "EHLO chaos.analogic.com") by vger.kernel.org with ESMTP id ; Wed, 3 Jul 2002 13:22:31 -0400 Date: Wed, 3 Jul 2002 13:25:31 -0400 (EDT) From: "Richard B. Johnson" Reply-To: root@chaos.analogic.com To: Pavel Machek cc: "Stephen C. Tweedie" , Bill Davidsen , Linux-Kernel Mailing List Subject: Re: simple handling of module removals Re: [OKS] Module removal In-Reply-To: <20020703034809.GI474@elf.ucw.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1065 Lines: 33 On Wed, 3 Jul 2002, Pavel Machek wrote: > Hi! > > Okay. So we want modules and want them unload. And we want it bugfree. > > So... then its okay if module unload is *slow*, right? > > I believe you can just freeze_processes(), unload module [now its > safe, you *know* noone is using that module, because all processes are > in your refrigerator], thaw_processes(). > > That's going to take *lot* of time, but should be very simple and very > effective. > Absolutely. Nobody cares if it takes many milliseconds to unload a module. We just don't want to take the 30 or more seconds necessary to reboot the machine (3 minutes on some embedded '486es with network boots). Cheers, Dick Johnson Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). Windows-2000/Professional isn't. - 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/