Date: Thu, 5 Feb 1998 01:58:11 -0800 From: John-Mark Gurney <gurney_j@efn.org> To: Ollivier Robert <roberto@keltia.freenix.fr> Cc: cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci brktree_reg.h brooktree848.c Message-ID: <19980205015811.03265@hydrogen.nike.efn.org> In-Reply-To: <19980205092542.01795@keltia.freenix.fr>; from Ollivier Robert on Thu, Feb 05, 1998 at 09:25:42AM %2B0100 References: <199802040748.SAA00670@godzilla.zeta.org.au> <34D8BA73.59E2B600@whistle.com> <19980204211555.00395@follo.net> <19980205092542.01795@keltia.freenix.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
Ollivier Robert scribbled this message on Feb 5: > According to Eivind Eklund: > > I don't think we'll have loadable modules for most of the drivers > > until at the _very_ least 1/2 yeaqr into the future, and by then we'll > > hopefully have DEVFS as a default and get rid of the option :-) > > Speaking of loadable modules, what happened to the new kld* loading system? > I thought it was to replace our current LKM... ? it will, right now I'm working on the new bus/device code so that we can actually do the dynamic loading and what not... does anybody object to me committing my patches that make VFS a bit more module friendly? (where we use SYSINITS to add the vnode_ops instead of doing it in a central routine) I've been using this system on a few of my -current machines for a while now and haven't noticed a problem... Terry did mention that there could be a problem if you loadded the ffs vnode ops before the ufs ops, but this can be solved by forcing the ufs load before ffs... as for making kld more stable, I haven't thought of a way to prevent the kld syscalls from panicing the system when you have a static kernel... there is the check around each call, but I don't like adding that much code... the other problem is that the kernel isn't loaded by the kld system, and in some ways this is a problem... it causes speical handling of the staticly compiled kernel modules... what would be ideal is for the boot blocks to load the kernel, and check for dependancies, and then load each required module... then pass in a struct with the required load order... as the kld system uses dynamicly allocated memory (does our malloc allow setting aside static data areas for allocation before malloc is initalized?) it always requires that the kernel be the first thing initalized... so the steps would be: load kernel find dependancies of foo and bar... load foo find dependancy on xyz load xyz load bar do a tsort on required modules and find that the load order is something like: xyz, foo, bar, kernel... pass addresses to these modules so that the kld system can run their sysinits... (there is a problem with merging the data sets and handling the symbol look up's properly when done like this)... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking P.O. Box 5693, 97405 Live in Peace, destroy Micro$oft, support free software, run FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980205015811.03265>