Date: Tue, 29 Dec 1998 02:16:24 +0800 From: Peter Wemm <peter@netplex.com.au> To: Kenneth Wayne Culver <culverk@wam.umd.edu> Cc: obrien@nuxi.ucdavis.edu, committers@FreeBSD.ORG Subject: Re: LKM future (was Re: The recent fracas involving danes, war axes and wounded developers ) Message-ID: <199812281816.CAA67058@spinner.netplex.com.au> In-Reply-To: Your message of "Mon, 28 Dec 1998 12:33:45 EST." <Pine.GSO.3.95q.981228123030.17098C-100000@rac10.wam.umd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Kenneth Wayne Culver wrote: > > > > I think it's important that if we ship the ability to load *old* a.out > > LKM's on an a.out kernel, then noise needs to be made or there will be > > messy accidents. > > > > What do folks think about making the LKM loading mechanism a kernel option > > and having it default to off.. > > > I think this is a good idea. It will allow for a transition period from > LKMs to KLDs, but, I think it should be in the GENERIC kernel, and should > just be an option with the disable keyword. That way, users can choose > whether or not they want to have this from install time, and they will > know that it is an option. I guess that would require GENERIC to be a.out, > but from what I have heard a.out is faster, and KLDs work in elf and a.out > kernels. Somebody let me know if this is a good suggestion. Enable/disable generally works on device drivers.. 'options LKM' wouldn't be a driver. a.out vs ELF speed wise are the same.. The executable code is the same, the only difference is the wrapping. Now, it may be faster to load a LKM than a KLD (I'd be a little suprised if this was the case) but it wouldn't really matter since it's a one-off event. What I think you're thinking of is a Linux thing.. They changed from absolute address a.out shared libraries to ELF (pic - position independent code). There is a slowdown there because PIC mode steals a register and makes the compiler code generator less efficient. For the kernel, this doesn't matter at all since both a.out and ELF kld's are *not* PIC. Apart from load/unload speed, there should be no difference at all. There are a couple of other issues.. KLD kernels have an embedded symbol table. Last I heard, this caused some release building problems since the kernel size is a tad bigger. This can be (I think) explicitly overridden at the expense of sysinstall-time kld support. I for one would much rather split the boot disk a little so that the more obscure drivers got moved off to a supplemental floppy and got loaded as needed. This would give us much better long term freedom for size problems. However, the real killer is... How long will current LKM's be useable? Not very long I suspect. The next time somebody changes an include file, the LKM's will become "stale" and need recompiling. Since this has been removed, LKM's will become dangerous. 3.0 LKM's will most likely not be useable on 3.0.1 (or -current). IMHO, we will be doing ourselves and the users a disservice if we let them load LKM's that are guaranteed to be stale and extremely dangerous. > Kenneth Culver Cheers, -Peter -- Peter Wemm <peter@netplex.com.au> Netplex Consulting "No coffee, No workee!" :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812281816.CAA67058>