Date: Thu, 31 Aug 1995 18:41:01 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: terry@lambert.org, 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: <199509010141.SAA23903@phaeton.artisoft.com> In-Reply-To: <12861.809917851@time.cdrom.com> from "Jordan K. Hubbard" at Aug 31, 95 06:10:51 pm
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). I think the Linux LKM system has shown enough of a win for putting them in kernel space that I'd like to at least try it. If it's not a win, it's not a win, and you go with the external object massager. Linux can run a lot of things as loadable modules and still not exceed the memory restriction for a kernel on a 4M machine. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509010141.SAA23903>