Date: Tue, 3 Nov 1998 21:56:21 -0500 (EST) From: Brian Feldman <green@zone.syracuse.net> To: Mike Smith <mike@smith.net.au> Cc: Chuck Robey <chuckr@mat.net>, Peter Wemm <peter@netplex.com.au>, John Hay <jhay@mikom.csir.co.za>, freebsd-current@FreeBSD.ORG Subject: Re: Booting Elf Kernel Message-ID: <Pine.BSF.4.05.9811032155120.5761-100000@zone.syracuse.net> In-Reply-To: <199811032124.NAA00500@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Not to be rude, but I did know this. I meant, tho, how a system to handle both lkm's and kld's could exist (user-level, like mount(8) etc.). It seems peter knows, according to his commits ;) Cheers, Brian Feldman On Tue, 3 Nov 1998, Mike Smith wrote: > > On Tue, 3 Nov 1998, Peter Wemm wrote: > > > > > Brian Feldman wrote: > > > > Ahhhh, that's where it is! I have no good idea on how to allow, with this > > > > code, lkm's and kld's to coexist.... so is it time to completely phase out > > > > lkm's yet? > > > > > > I think the best way is to have mount(2) initiate a kldload if needed. We > > > will need this functionality sooner or later. If mount(2) does it, we can > > > garbage collect unused, unmounted filesystems after a while and unload > > > them. > > > > Peter, you once told me that the new elf kernel has both aout and elf > > linkers in it. Does an elf kernel have the ability to load lkm modules, > > not the .ko things? If so, then the mount stuff is going to need to > > know which kind of module to hunt for, to load, right? Or, if they both > > work, maybe find both, and load the newest? With maybe a kld bias for a > > tiebreaker? > > Peter has already answered this pretty well; let me just clarify a few > things which will hopefully help understanding. > > The old LKM model was somewhat ugly; it worked like this: > > LKM's were built as relocatable objects. To load an LKM, you used the > a.linker to link the LKM object against the kernel file. The newly > relocated object was then copied into kernel space. This procedure was > dependant on having writable disk space (for the relocated object), the > a.out linker present, and could not be initiated from inside the kernel. > > In contrast, the new (KLD) approach works like this: > > A KLD module load is initiated by passing the pathname of the module to > the kernel. The kernel itself reads the object into memory, relocates > it at the new location, resolves any dependancies, connects SYSINITs, > etc. This can be done off a completely read-only filestore, and in > fact the kernel doesn't even have to read the modules in; they can be > placed in advance by the bootloader. > > You could, theoretically, load both LKMs and KLD modules into an a.out > kernel. You can't do anything with LKMs that involves an ELF object, > either the LKM or the kernel. > > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9811032155120.5761-100000>