Date: Sun, 11 Oct 1998 08:43:11 +0800 From: Peter Wemm <peter@netplex.com.au> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: Doug Rabson <dfr@nlsystems.com>, "Robert V. Baron" <rvb@cs.cmu.edu>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/sys kernel.h Message-ID: <199810110043.IAA18053@spinner.netplex.com.au> In-Reply-To: Your message of "Sat, 10 Oct 1998 15:06:20 CST." <199810102113.PAA24678@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Justin T. Gibbs" wrote: > >This is directly addressed by the KLD system. The terminology is that a > >'file' (ELF or a.out) is loaded by the kernel linker. The file contains a > >number of 'modules', each of which is initialised and has an event handler > >(similar to lkmdispatch). The kernel in many ways is a file which > >contains all the statically linked modules. > > How are module dependencies represented and honored? Not exceptionally well at present as I understand it. There are a couple of mechanisms in place, and some complications and problems. This needs to be revisited. First of all, keep in mind that module creation is essentially free-form. You can bundle any number of modules into one .ko file. Since there isn't necessarily going to be a 1:1 relationship between modules and files, you can't intuit a filename from a missing module dependency in order to autoload it. For now, we have to assume that the user knows what they are doing. Second, it's also enforced at the linker level. A module load will be rejected if it depends on symbols that are not present. Ideally though it should be pretty much self contained. If you are wondering about (say) a CAM module, SCSI device type (eg: da, cd) modules and device drivers (eg: ahc), this can be done at .ko build time via normal shared-libarary-like dependencies. The hacked bsd.kmod.mk that I use can handle this to a degree. It ends up looking like this: peter> objdump --all-headers `obj`/testmod.ko | more [..] Dynamic Section: NEEDED cam.ko HASH 0x94 STRTAB 0x198 [..] Both /boot/loader and kldload() will see the NEEDED tag and load it if it's not present. You can stick in version numbers into the name. Obviously you need to take care there, because there are some shoot-in-the-foot type possibilities if you have cam.ko loaded and the cam stuff is present within the kernel already. Mike had a fairly elaborate system in place that was implemented within /boot/loader but not in the kernel proper. I disabled it because it required hard coding filename dependencies into the source code and because it could be done better other ways. What is needed is that the linker and module engine should reject an attempt to load files with module names that are already present, and we need some sort of module versionining moreso than file versioning. A variation of Mike's scheme would be useful here and can be hooked onto the moduledata_t attached to the module declaration. I could imagine some sort of registry of versions of modules provided by the src/sys code somewhere. If an include file had: #define MODVER_CAM 300126 /* CAM driver */ and the scsi_da.c driver did a #include <sys/modver.h> or something and specified a dependency ala .... { "cam", MODVER_CAM }, .... somewhere in it's metadata, then the linker and module engines could check for prerequisites and correct versions. It could enable a forced recompile of the cam related modules if there was some incompatable change made. There would also presumably be some dependency on some version of "kernel" as well. Of course, one could force the issue via the linker.. Somewhere in the cam code: int cam_300126 = <minor version>; and in consumers of CAM in their init code: extern int cam_300126; ... if (cam_300126 < 10) printf("Warning: your version of CAM is too old\n"); ... Naturally it'd be nicer to have the module engine do this rather than duplicating hacks like this all over the place. Anyway, what we have now is no worse than the current LKM system, but has room to be made a lot better. Cheers, -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810110043.IAA18053>