From owner-freebsd-current Thu Aug 31 19:31:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id TAA06394 for current-outgoing; Thu, 31 Aug 1995 19:31:04 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id TAA06382 for ; Thu, 31 Aug 1995 19:30:57 -0700 Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.12/8.6.5) with ESMTP id TAA23803; Thu, 31 Aug 1995 19:29:46 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id TAA22268; Thu, 31 Aug 1995 19:31:44 -0700 Message-Id: <199509010231.TAA22268@corbin.Root.COM> To: Terry Lambert cc: jkh@time.cdrom.com (Jordan K. Hubbard), bde@zeta.org.au, wollman@lcs.mit.edu, freebsd-current@freebsd.org, jhay@mikom.csir.co.za Subject: Re: pseudo device lkm's broken In-reply-to: Your message of "Thu, 31 Aug 95 18:41:01 PDT." <199509010141.SAA23903@phaeton.artisoft.com> From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 31 Aug 1995 19:31:00 -0700 Sender: current-owner@freebsd.org Precedence: bulk >> So, given that the interdependency set between LKM and kernel is even >> smaller with this, do you think there's any chance of us being able to >> remove ld from the equation at some point? It would be nice if the >> kernel could load them directly, without requiring a user mode program >> to run interferance first. > >Garrett and I disagree on this point; it has to do with me being probably >over-optimistic as to how much linker code you'd have to drag into the >kernel and Garret being overly pessimistic on the same point. 8-). > >I think the main issue is the existing kernel symbol space for exported >kernel interfaces, and how it would be bloated (or not) by putting the >symbol list inside the kernel as opposed to leaving them in an ld -r'ed >kernel symbol image somewhere (what the LKM loader currently does). Yeah, I think this is a large part of the issue. It would nice to have the symbols, anyway, so that we can provide the operator with a traceback when the system crashes. I get so tired of telling people how to lookup symbols with 'nm /kernel'. ...but this will cost us about 100K more kernel bloat. Sigh. I really am getting to the point where I think that booting in 4MB will no longer be possible in the near future. -DG