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>