From owner-freebsd-hackers Mon Jun 5 16:48:20 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.234]) by hub.freebsd.org (Postfix) with ESMTP id 8640637B84D for ; Mon, 5 Jun 2000 16:48:15 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id QAA00547; Mon, 5 Jun 2000 16:51:28 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200006052351.QAA00547@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Jeroen C. van Gelderen" Cc: hackers@FreeBSD.ORG Subject: Re: kerneld for FreeBSD In-reply-to: Your message of "Mon, 05 Jun 2000 16:46:44 EDT." <393C11B4.D40B9EBD@vangelderen.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Jun 2000 16:51:28 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > and if a module wants to unload itself due to > > "unuse", it can already do so. > > You wouldn't have control over that process if the modules decides > for itself. It's a sysadmin decision to unload modules, not the > module's decision. So why introduce a third party? ("kerneld") If the admin wants to remove a module, great. TBH, unloading an idle module is basically a waste of time. Modules are, on the whole, so small that the savings are entirely outweighed by the unnecessary complexity. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message