Date: Thu, 31 Aug 1995 19:31:00 -0700 From: David Greenman <davidg@Root.COM> To: Terry Lambert <terry@lambert.org> 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 Message-ID: <199509010231.TAA22268@corbin.Root.COM> In-Reply-To: Your message of "Thu, 31 Aug 95 18:41:01 PDT." <199509010141.SAA23903@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509010231.TAA22268>