From owner-freebsd-hackers Wed Jan 3 03:22:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA00615 for hackers-outgoing; Wed, 3 Jan 1996 03:22:26 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA00603 for ; Wed, 3 Jan 1996 03:22:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id DAA07743; Wed, 3 Jan 1996 03:19:41 -0800 To: A JOSEPH KOSHY cc: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: Demand loading (Re: FreeBSD, Zappa & PCI) In-reply-to: Your message of "Wed, 03 Jan 1996 16:01:06 +0530." <199601031031.AA299195067@fakir.india.hp.com> Date: Wed, 03 Jan 1996 03:19:41 -0800 Message-ID: <7741.820667981@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > Well, it would be nice to be able to delay loading a driver till needed. > Even nicer would be the ability to unload and reload a driver on the fly. > > This would allow customers to update portions of the kernel without > having to bring the system down, (well, in theory, anyway :)). That's basically where devfs and the LKM mechanisms are heading, though I don't know if proper `unloading' has been properly instrumented yet (e.g. with depends). > Can someone explain why we need ELF or its equivalent for this > to be feasible? I don't think we do at all. It wouldn't be *that* hard to do with our current a.out format, and I think the first big thing we need to do is implement a `lighter weight' LKM mechanism that doesn't rely on /usr/bin/ld to load things into the kernel, otherwise you run into a chicken-and-egg problem loading disk drivers dynamically. There's the `fasl' code in gcl (/usr/ports/lang/gcl) to look at, though it's somewhat simplistic and requires that you extract all the symbol names from the target first using another utility. Jordan